Re: [gentoo-dev] Ideas for a (fast) EAPI=3

[Mart Raudsepp]

Hello,

On Sun, 2009-03-08 at 08:49 +0100, Tiziano Müller wrote:

> With eapis 1 and 2 we introduced nice features but also a couple of
> new
> problems. One of them are the use dependencies when the package you
> depend on doesn't have the use flag anymore (see [1] for an example).
>
> So I think it's time for a short eapi bump with some distinct
> improvements:
>
> http://spreadsheets.google.com/ccc?key=pPAJXP6shYH78lCXeqRqCUQ
>
>
> Please discuss.


Sorry for getting my points of discussion on the details to the list so
late.
I have covered some of my concerns on the items in meetings and
otherwise on IRC, but now I'll try to get to them in further detail and
better wording to the mailing list.

I'm going to go item-by-item here for the things I don't expect much
replies to, and then starting separate threads for those that I do.


pkg_pretend
===========

No objections.
Gives an intermediate step for handling USE flag combination
incompatibilities at pretend stage (to not find it failed in the
morning), yet has uses outside that as well. So, once there is a way to
express those kind of USE flag dependencies outside of pkg_pretend in a
better way in a future EAPI, pkg_pretend will still be useful for other
(less common) cases and can provide a description of the problem to the
user.


Use based deps with non-existing USE flags
==========================================

No objections.
Implements the missing bit of "built_with_use --missing"
Main driving force behind EAPI-3.


default src_install
===================

No considerable input yet, catching up with the latest thread about
src_install bikeshedding


doinclude
=========

Unnecessary. Might be interesting for automatic executable permission
removing, but upstream build systems should be fixed instead for such a
big and rare error.


ban dosed
=========

I don't exactly see a reason for the banning yet, but no objections due
to general agreement on it and having no technical objections


doins support for symlinks
==========================

Lacking information. Need to see if the PMS draft has anything about it.
The bug and summaries just talk about the support, but no details. Would
it be an argument to doins?


unpack failing on unknown types
===============================

Uncertain about it's worthiness. Might rather have the opposite with a
--strict argument kind of deal. No official objection from me.


docompress
==========

Need some more time to digest through it in relation to
PORTAGE_COMPRESS, prepalldocs and co. Will try to follow-up before
meeting.


properties must be cached properly
==================================

No opinion, up to the package manager developers.
Don't see offhand why it should be an EAPI item at all. Feels like an
implementation detail.


DEFINED_PHASES must be supported (and cached properly)
======================================================

No opinion, up to the package manager developers more or less.
Not sure why this needs to be an EAPI item. Hard to see a use case for
the variable being available for ebuild usage for it to be necessary to
be an EAPI item.
By my understanding it is (also?) a required implementation detail to
handle pkg_pretend sanely and with minimal time hit.


Limit values in $USE to ones in $IUSE:
======================================

Seems more of a QA test, but forcing it can make it be caught at start.
Don't see why it must be an EAPI item. Just vet the tree of (future?)
repoman warnings about it and make it happen for
all EAPIs. Impact on overlays is minimal because it is a QA error to not
define them and they get what they asked for.

Not strongly opposed to it being in the EAPI.


--disable-dependency-tracking:
==============================

possible breakage of (custom) configure scripts that don't accept
unknown arguments. Would be nice to pass that for most packages, but
doing it always with econf seems slightly inappropriate, given the
above.
Don't think this is an item for fast-tracked EAPI-3.


utility commands should die by default
======================================

Would like to see a list of those utility commands that would be made to
die by default.


ban || ( foo? ( . ) . )
=======================

It is not the business of an EAPI to start disallowing *DEPEND string
constructs.
There is no useful alternative provided yet to my knowledge and this is
really a QA issue, not an EAPI issue.
Not convinced on the sub-optimal use case being the only one, either.

Strongly objecting on the grounds that it is not something that should
be an EAPI issue.


unpack has to handle more types
===============================

Would be nice to get a QA warning when unpacking .lzma, .xz, etc that
need a build depend for the unpacker and don't have it yet. Then sounds
fine.



In separate threads:
* Slot operator support
* dohard being deprecated


Did I miss anything?
I'm not even sure anymore where to find a list of items that is current
for what's on the table for EAPI-3 right now...

-- 
Mart Raudsepp
Gentoo Developer
Mail: leio@g.o
Weblog: http://planet.gentoo.org/developers/leio