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

["Tiziano Müller" <dev-zero@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 6557 bytes --]

Am Donnerstag, den 09.04.2009, 04:51 +0300 schrieb 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.

The metadata cache needs to be specified to make it work with compliant
PM's and is therefore a part of the PMS.
A change is therefore required to be done on a per-EAPI base.

> 
> 
> 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.
> 
Why it has to be done in an EAPI: It matters whether you have to put for
example userland_GNU in IUSE if you want to use it in the ebuild or not.


> 
> --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.

custom configure scripts mostly already break with econf, so not an
issue.

> 
> 
> utility commands should die by default
> ======================================
> 
> Would like to see a list of those utility commands that would be made to
> die by default.
basically all do* commands.

> 
> 
> ban || ( foo? ( . ) . )
> =======================
> 
> It is not the business of an EAPI to start disallowing *DEPEND string
> constructs.
It's EAPI's business to define what's valid and what is not.

> There is no useful alternative provided yet to my knowledge and this is
> really a QA issue, not an EAPI issue.
The problem is that there is no valid use case to justify the existence
of this construct. In either way users will most likely not have what
they want if "|| ( foo? ( . ) . )" is being used. Disallowing it will
therefore help the user to get what the specified and is therefore a
good thing.

> 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.
But you don't want unpack fail on unknown types? Seems a bit
inconsequent.

> 
> 
> 
> 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...
> 
The PMS. (just do "emerge pms" for an up-to-date version).


[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 198 bytes --]