From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1LrrkI-0000WO-KX for garchives@archives.gentoo.org; Thu, 09 Apr 2009 10:44:34 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 5A4F5E0501; Thu, 9 Apr 2009 10:44:33 +0000 (UTC) Received: from smtp-out.neti.ee (smtp-out.neti.ee [194.126.126.44]) by pigeon.gentoo.org (Postfix) with ESMTP id D0E9CE0501 for ; Thu, 9 Apr 2009 10:44:32 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by MXR-13.estpak.ee (Postfix) with ESMTP id 7F76E28A42 for ; Thu, 9 Apr 2009 13:44:29 +0300 (EEST) X-Virus-Scanned: amavisd-new at !change-mydomain-variable!.example.com Received: from smtp-out.neti.ee ([127.0.0.1]) by localhost (MXR-1.estpak.ee [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pYlfTn287bfP for ; Thu, 9 Apr 2009 13:44:23 +0300 (EEST) Received: from Relayhost2.neti.ee (Relayhost2 [88.196.174.142]) by MXR-13.estpak.ee (Postfix) with ESMTP id 97ABD57C59 for ; Thu, 9 Apr 2009 13:44:23 +0300 (EEST) X-SMTP-Auth-NETI-Businesmail: no Subject: Re: [gentoo-dev] Ideas for a (fast) EAPI=3 From: Mart Raudsepp To: gentoo-dev@lists.gentoo.org In-Reply-To: <1239266248.7303.54.camel@localhost> References: <1236498557.6854.51.camel@neuromancer> <1239241866.29054.38.camel@localhost> <1239266248.7303.54.camel@localhost> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-lW4nseYFC0tIITrJ4y1U" Date: Thu, 09 Apr 2009 13:44:55 +0300 Message-Id: <1239273896.988.12.camel@localhost> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 X-Mailer: Evolution 2.22.0 X-Archives-Salt: f051ce39-1ea4-40df-ad0c-4e3558eb8dd7 X-Archives-Hash: 0ba362f44cc9d2d006831be612994ffa --=-lW4nseYFC0tIITrJ4y1U Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On N, 2009-04-09 at 10:37 +0200, Tiziano M=FCller wrote: > > properties must be cached properly > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >=20 > > 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. >=20 > 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: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >=20 > > 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. > >=20 > > Not strongly opposed to it being in the EAPI. > >=20 > 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. >=20 > >=20 > > --disable-dependency-tracking: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > >=20 > > 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. >=20 > 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? ( . ) . ) > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >=20 > > 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. > >=20 > > Strongly objecting on the grounds that it is not something that > should > > be an EAPI issue. > >=20 > >=20 > > unpack has to handle more types > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > >=20 > > 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... > >=20 > The PMS. (just do "emerge pms" for an up-to-date version). that's a bit complicated with not having texlive installed anywhere yet... --=20 Mart Raudsepp Gentoo Developer Mail: leio@gentoo.org Weblog: http://planet.gentoo.org/developers/leio --=-lW4nseYFC0tIITrJ4y1U Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.8 (GNU/Linux) iEYEABECAAYFAknd0acACgkQkeYb6olFHJduuwCgzV2PURjqa3xcEUk+Q53FN/AQ xoQAnjbO40F51QesS4Sxmwa4hlD5JB2G =gIpo -----END PGP SIGNATURE----- --=-lW4nseYFC0tIITrJ4y1U--