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 1Lh87K-0001PH-VZ for garchives@archives.gentoo.org; Tue, 10 Mar 2009 19:59:59 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6BE8DE04F5; Tue, 10 Mar 2009 19:59:57 +0000 (UTC) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.250]) by pigeon.gentoo.org (Postfix) with ESMTP id 1FF4AE04F5 for ; Tue, 10 Mar 2009 19:59:57 +0000 (UTC) Received: by an-out-0708.google.com with SMTP id c2so1252214anc.1 for ; Tue, 10 Mar 2009 12:59:56 -0700 (PDT) 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 Sender: cardoe@cardoe.com Received: by 10.100.11.14 with SMTP id 14mr4806965ank.89.1236715196223; Tue, 10 Mar 2009 12:59:56 -0700 (PDT) In-Reply-To: <20090309202624.723e4b2a@snowcone> References: <1236498557.6854.51.camel@neuromancer> <20090309202624.723e4b2a@snowcone> Date: Tue, 10 Mar 2009 14:59:56 -0500 X-Google-Sender-Auth: 9d28bc3416993f9e Message-ID: Subject: Re: [gentoo-dev] Ideas for a (fast) EAPI=3 From: Doug Goldstein To: gentoo-dev@lists.gentoo.org Content-Type: multipart/alternative; boundary=0016e642dd64f5a05e0464c93199 X-Archives-Salt: 873a6839-cf8d-4245-90f9-49b012464957 X-Archives-Hash: d133dec4d00c110147f543bf37dd9420 --0016e642dd64f5a05e0464c93199 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Mar 9, 2009 at 3:26 PM, Ciaran McCreesh < ciaran.mccreesh@googlemail.com> wrote: > On Sun, 08 Mar 2009 08:49:16 +0100 > Tiziano M=C3=BCller wrote: > > http://spreadsheets.google.com/ccc?key=3DpPAJXP6shYH78lCXeqRqCUQ > > Here're some more easy ones. > > First up, un-optionaling some optional things. No impact for developers: > > * PROPERTIES must be cached properly (it's optional in current EAPIs) +1 from me > > > * DEFINED_PHASES must be supported (ditto) +1 from me > > > Next, some probably easy but long standing features: > > * src_test run unless RESTRICTed or explicitly disabled by the user (bug > 184812) I'd love to but please look at the most recent comment I've made on the bug > > > * have econf run ./configure with --disable-dependency-tracking and > --enable-fast-install (bug 211529) +1 from me. Did we ever test autoconf 2.13 based stuff? > > > * Limit values in $USE to ones in $IUSE (bug 176467). The existing > behaviour's majorly annoying; time for the package manager to start > enforcing things strictly. definitely +1 from me. I've been trying to put kernel_linux and such in my ebuilds already to improve this. > > > Some things we should probably sort out: > > * The list of extensions for unpack probably needs a couple of new > things. We also need a way for the actual program being used for the unpack to be added to DEPEND. > > > * Provide ebuilds a way to differentiate between updates and removals > (bug 205557), since the way devmanual says to do it got broken by a > non-EAPIed change. This one's slightly trickier than initially > apparent, because a solution's needed for the weird cases. One > example is if you have foo-1:1 and foo-2:2 installed, and you're > installing foo-2:1. In this case, it's both a reinstall and an > upgrade. One possibility is a REPLACING_VERSIONS variable that > contains a list of all versions being replaced, along with a > REPLACED_BY_VERSION variable for the pre/postrm part. +1 from me > > > Not sure if these can go in in time for Portage or not: > > * Utility commands, even the ones that aren't functions, should die. To > get a non-die version, prefix the command with nonfatal (e.g. > 'nonfatal dodoc README', which just returns non-zero on failure > rather than splatting). +1 from me > > > * Calling unpack on an unrecognised extension should be fatal, unless > --if-compressed is specified. The default src_unpack needs to use > this. +1 from me > > > * pkg_info should work on things that aren't installed, as well as > things that are. We'd need to properly educate people about this because I'm pretty sure a bunch of pkg_info()'s require the actual package to be installed currently. > > > -- > Ciaran McCreesh > --0016e642dd64f5a05e0464c93199 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Mar 9, 2009 at 3:26 PM, Ciaran McCreesh <ciaran.mccreesh@googlemail.com= > wrote:
On Sun, 08 Mar 2009 08:49:16 +0100
Tiziano M=C3=BCller <dev-zero@gen= too.org> wrote:
> http://spreadsheets.google.com/ccc?key=3DpPAJXP6sh= YH78lCXeqRqCUQ

Here're some more easy ones.

First up, un-optionaling some optional things. No impact for developers:
* PROPERTIES must be cached properly (it's optional in current EAPIs)

+1 from=C2=A0 me


* DEFINED_PHASES must be supported (ditto)
=C2=A0
+1 from me


Next, some probably easy but long standing features:

* src_test run unless RESTRICTed or explicitly disabled by the user (bug =C2=A0184812)

I'd love to but please look at the = most recent comment I've made on the bug


* have econf run ./configure with --disable-dependency-tracking and
=C2=A0--enable-fast-install (bug 211529)

+1 from me. = Did we ever test autoconf 2.13 based stuff?


* Limit values in $USE to ones in $IUSE (bug 176467). The existing
=C2=A0behaviour's majorly annoying; time for the package manager to st= art
=C2=A0enforcing things strictly.

definitely +1 from m= e. I've been trying to put kernel_linux and such in my ebuilds already = to improve this.


Some things we should probably sort out:

* The list of extensions for unpack probably needs a couple of new
=C2=A0things.

We also need a way for the actual progr= am being used for the unpack to be added to DEPEND.


* Provide ebuilds a way to differentiate between updates and removals
=C2=A0(bug 205557), since the way devmanual says to do it got broken by a<= br> =C2=A0non-EAPIed change. This one's slightly trickier than initially =C2=A0apparent, because a solution's needed for the weird cases. One =C2=A0example is if you have foo-1:1 and foo-2:2 installed, and you're=
=C2=A0installing foo-2:1. In this case, it's both a reinstall and an =C2=A0upgrade. One possibility is a REPLACING_VERSIONS variable that
=C2=A0contains a list of all versions being replaced, along with a
=C2=A0REPLACED_BY_VERSION variable for the pre/postrm part.

+1 from me


Not sure if these can go in in time for Portage or not:

* Utility commands, even the ones that aren't functions, should die. To=
=C2=A0get a non-die version, prefix the command with nonfatal (e.g.
=C2=A0'nonfatal dodoc README', which just returns non-zero on fail= ure
=C2=A0rather than splatting).

+1 from me


* Calling unpack on an unrecognised extension should be fatal, unless
=C2=A0--if-compressed is specified. The default src_unpack needs to use =C2=A0this.

+1 from me


* pkg_info should work on things that aren't installed, as well as
=C2=A0things that are.

We'd need to properly educ= ate people about this because I'm pretty sure a bunch of pkg_info()'= ;s require the actual package to be installed currently.


--
Ciaran McCreesh

--0016e642dd64f5a05e0464c93199--