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: l...@gentoo.org Weblog: http://planet.gentoo.org/developers/leio
signature.asc
Description: This is a digitally signed message part
