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 1LrvJK-0008Nz-EK for garchives@archives.gentoo.org; Thu, 09 Apr 2009 14:32:58 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 2B750E06B2; Thu, 9 Apr 2009 14:32:56 +0000 (UTC) Received: from mail-bw0-f172.google.com (mail-bw0-f172.google.com [209.85.218.172]) by pigeon.gentoo.org (Postfix) with ESMTP id 973A2E06B2 for ; Thu, 9 Apr 2009 14:32:55 +0000 (UTC) Received: by bwz20 with SMTP id 20so574432bwz.34 for ; Thu, 09 Apr 2009 07:32:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type; bh=7zK1G/jUMCqH0D2cAIsiXIA5rjxgiuv9NBU630kIUYc=; b=LXMVbtW1J0Bt9DXdhiMNh7fobobiaIaiAmD0y1tGTQ3858GgyuY7eo10yMjX1PQkVy IMRR2fgEyEk4hgVVzvhY3agbepBP5rizhmfvLSvwm2mv5r0WXCvgwxUUnrKlUycQgsbD jYb4x347jP+mWJHAf71HSWtnCrvRzZZDcFHfg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; b=KkGYYrvIqa7Fr63dE3eU20lkwqNkrnJIGMJdkTurAkg67i5peP52/tqhb8L7FYbVbR Jlp1UyfB8xBEhXF+KRpOHyHbjQ+qXQKp5mkpkrFx42NPBo4haYy6uUmUgl8O7e+sf61L D7YTYU8FO3MbuJ2uFPxMnr2KS0OkA4nuNc1so= Received: by 10.103.117.8 with SMTP id u8mr1270676mum.123.1239287574668; Thu, 09 Apr 2009 07:32:54 -0700 (PDT) Received: from snowcone (92-235-187-79.cable.ubr18.sgyl.blueyonder.co.uk [92.235.187.79]) by mx.google.com with ESMTPS id y2sm591924mug.15.2009.04.09.07.32.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 09 Apr 2009 07:32:54 -0700 (PDT) Date: Thu, 9 Apr 2009 15:32:46 +0100 From: Ciaran McCreesh To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Ideas for a (fast) EAPI=3 Message-ID: <20090409153246.2dda1026@snowcone> In-Reply-To: <1239241866.29054.38.camel@localhost> References: <1236498557.6854.51.camel@neuromancer> <1239241866.29054.38.camel@localhost> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.14.7; x86_64-pc-linux-gnu) 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 Content-Type: multipart/signed; boundary="Sig_/.r2CIKLD8rVyVmJO_b4mNeF"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-Archives-Salt: 40cf20c7-f2e9-473f-a3a9-8196f8390598 X-Archives-Hash: f21aacb8f63d5494a50a10858e5996c7 --Sig_/.r2CIKLD8rVyVmJO_b4mNeF Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Thu, 09 Apr 2009 04:51:06 +0300 Mart Raudsepp wrote: > doins support for symlinks > =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 > 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? The PMS draft explains it. It's simple, though: currently, doins on a symlink does something arbitrary. We want it to install the symlink. > unpack failing on unknown 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 > Uncertain about it's worthiness. Might rather have the opposite with a > --strict argument kind of deal. No official objection from me. What with the moving towards auto-die, the trend is towards "strict unless explicitly told not to be". > 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. The cache format's tied to EAPI in a fairly unpleasant manner. It's a necessary evil. > DEFINED_PHASES must be supported (and 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=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 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. DEFINED_PHASES isn't available to the ebuild. But it is in the metadata cache, which PMS has to cover. > By my understanding it is (also?) a required implementation detail to > handle pkg_pretend sanely and with minimal time hit. Correct. Without it there's a delay of ~0.1s per ebuild in the resolution set at pretend time, which soon adds up for certain reasonably common use cases. > 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. It needs to be in EAPI because we're talking about changing how the ebuild environment is specified. Also, repoman can't catch most accidental abuses of this. > --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. Please provide a list of packages that use custom configure scripts, that currently work with econf (including all the weird things it already passes), that would break with this change and whose ebuilds are using econf. I have yet to see any examples provided. > utility commands should die by default > =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 > Would like to see a list of those utility commands that would be made > to die by default. The PMS draft has one. > 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. > There is no useful alternative provided yet to my knowledge and this > is really a QA issue, not an EAPI issue. There is no use case for the construct anyway. > 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. Behaviour of || ( foo? ( . ) ) is already an EAPI issue, and has a horrible section of PMS devoted to explaining its quirky behaviour. > 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... Do a git log on the PMS draft (or look at the summary table in the appendix). It's fairly close to one commit per EAPI item. --=20 Ciaran McCreesh --Sig_/.r2CIKLD8rVyVmJO_b4mNeF Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkneBxAACgkQ96zL6DUtXhES8gCfeAVoulJ/xgvdEIRJsIWMPt6t exwAnAprFD/31nSPdlMQ19vUD6v/Ej/S =4l6W -----END PGP SIGNATURE----- --Sig_/.r2CIKLD8rVyVmJO_b4mNeF--