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

[Mart Raudsepp]

On N, 2009-04-09 at 10:37 +0200, Tiziano Müller wrote:
> > 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.

But the metadata cache isn't per-EAPI in the sense of multiple metadata
caches, one for each EAPI. There might be per-EAPI metadata cache items
though.
Anyhow, if zmedico is cool with it, I'm cool.

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

I don't think I want to have to specify userland_GNU and co in IUSE.
They aren't USE flags that get set by the user, so having to put them in
IUSE isn't intuitive either.

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

Some might accept all current switches we pass with econf, but not
--disable-dependency-tracking.
Maybe if there's a way to opt out of the --disable-dependency-tracking
when necessary... the unlikely need for that will get seen by the
maintainer when he/she upgrades the ebuild to EAPI-3.
econf is a complex and long (many arguments passed) beast to replicate
just without --disable-dependency-tracking

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

We disagree there. Things should be an EAPI item when it is reasonably
required to be. In this case a simple repoman warning on such a
construct suffices.

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

Then we should disallow all constructs that currently give a repoman
warning as well?
It is a QA issue to me, not something to overload an EAPI with.
QA warning for all EAPI's.

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

Unknown types in this case is about "not packed at all".
Or we could define those types - .patch, .bin, etc
PM knows that there's .lzma, .xz and so on, so it could know which
build-time deps are necessary - repoman warning anyhow, later some
alternative unpacker might surface.

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

that's a bit complicated with not having texlive installed anywhere
yet...



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