From: Pacho Ramos <pacho@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Re: [RFC] Drop EAPI=0 requirement for system packages.
Date: Wed, 17 Oct 2012 19:34:38 +0200 [thread overview]
Message-ID: <1350495278.2447.33.camel@belkin4> (raw)
In-Reply-To: <20121016234230.3b79a2fe@gentoo.org>
[-- Attachment #1: Type: text/plain, Size: 1880 bytes --]
El mar, 16-10-2012 a las 23:42 -0600, Ryan Hill escribió:
> On Sat, 13 Oct 2012 08:28:20 +0200
> Ralph Sennhauser <sera@gentoo.org> wrote:
>
> > On Fri, 12 Oct 2012 21:10:23 -0600
> > Ryan Hill <dirtyepic@gentoo.org> wrote:
> >
> > > I'd argue against deprecating EAPI 0 any time soon though. Killing
> > > EAPI 1 would be a better idea.
> >
> > I'm not for forced EAPI bumps anytime soon, but I expect EAPI 0 to be
> > gone from tree in 3-5 years once the EAPI=0 requirement is lifted.
>
> How many packages in the tree don't define EAPI at all? It's been a while
> since I looked, but I remember it was a pretty big number. Maybe things have
> changed.
>
> > Currently we have only 6 official EAPIs which is still manageable to
> > remember the details of each. Though it might be confusing for new
> > developers. Once we are at 20 EAPIs it will be an issue also for
> > seasoned folks.
>
> Agreed. We will definitely have to do some pruning at some point.
Would be easier to prune old versions if we "force" them to be less
using at least preventing new ebuilds to use them. For example, what is
the advantage for a new ebuild to still rely on old src_compile phase
instead of src_prepare/configure...?
>
> > Therefore deprecation is a given, how to go about it is certainly up to
> > discussion. What do you see as an acceptable path here?
>
> I think an EAPI becomes a candidate for removal when the number of packages
> using it becomes small enough that a sufficiently motivated/bored/gullible
> person could take on the task of porting them all to a newer EAPI. EAPI 0 is
> our baseline (all EAPIs are defined as "EAPI 0 plus/minus foo") and thus
> should never* be removed. Anything else is fair game.
>
>
> *for varying lengths of never. If it becomes completely irrelevant then
> yeah just boot it.
>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
next prev parent reply other threads:[~2012-10-17 17:35 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-12 10:53 [gentoo-dev] [RFC] Drop EAPI=0 requirement for system packages Ralph Sennhauser
2012-10-12 20:38 ` Walter Dnes
2012-10-12 20:41 ` Ciaran McCreesh
2012-10-12 20:45 ` Ian Stakenvicius
2012-10-12 21:02 ` Alexandre Rostovtsev
2012-10-13 3:10 ` [gentoo-dev] " Ryan Hill
2012-10-13 6:28 ` Ralph Sennhauser
2012-10-17 5:42 ` Ryan Hill
2012-10-17 17:34 ` Pacho Ramos [this message]
2012-10-17 19:00 ` Rich Freeman
2012-10-18 4:07 ` Ryan Hill
2012-10-18 13:36 ` Rich Freeman
2012-10-18 15:49 ` Pacho Ramos
2012-10-18 17:49 ` Rich Freeman
2012-10-18 19:05 ` Pacho Ramos
2012-10-18 19:35 ` Rich Freeman
2012-10-19 17:21 ` Pacho Ramos
2012-10-19 17:51 ` Alexis Ballier
2012-10-19 18:09 ` Pacho Ramos
2012-10-19 18:47 ` Alexis Ballier
2012-10-19 19:32 ` Pacho Ramos
2012-10-19 19:43 ` Thomas Sachau
2012-10-19 19:53 ` Pacho Ramos
2012-10-19 20:39 ` Thomas Sachau
2012-10-19 20:47 ` Rich Freeman
2012-10-20 6:04 ` Pacho Ramos
2012-10-20 14:09 ` Thomas Sachau
2012-10-20 14:29 ` Pacho Ramos
2012-10-20 14:53 ` Pacho Ramos
2012-10-20 15:15 ` Thomas Sachau
2012-10-20 15:19 ` Pacho Ramos
2012-10-20 15:17 ` Pacho Ramos
2012-10-20 15:57 ` Thomas Sachau
2012-10-20 15:24 ` Rich Freeman
2012-10-19 20:43 ` Alexis Ballier
2012-10-20 6:07 ` Pacho Ramos
2012-10-20 6:14 ` Michał Górny
2012-10-20 6:31 ` Pacho Ramos
2012-10-20 14:37 ` Peter Stuge
2012-10-19 4:09 ` Ryan Hill
2012-10-19 4:34 ` Zac Medico
2013-04-12 16:25 ` [gentoo-dev] Binary package dependencies for sub-slot-less EAPIs W. Trevor King
2013-04-12 18:38 ` Rich Freeman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1350495278.2447.33.camel@belkin4 \
--to=pacho@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox