From: Rich Freeman <rich0@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 15:00:12 -0400 [thread overview]
Message-ID: <CAGfcS_krHpQd4ocjLV6taPDhde6FgNaHVOgzurJob2Q+safJXQ@mail.gmail.com> (raw)
In-Reply-To: <1350495278.2447.33.camel@belkin4>
On Wed, Oct 17, 2012 at 1:34 PM, Pacho Ramos <pacho@gentoo.org> wrote:
> 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...?
It can be bumped by copying it from the ebuild for the previous
version, thus introducing no errors. Or maybe the person who authored
it (who might or might not even be a developer) isn't familiar with
the latest EAPI, but the code still works.
A policy that says all new ebuilds shall use EAPI foo might result in
fewer new ebuilds. Sure, they'll have new and shiny fooness, but
arguably I'd rather have more packages supported on older EAPIs then
fewer packages supported on newer ones.
Again, as I stated before, things that actually benefit the end users
like slot dependencies are fine to mandate when it makes sense to do
so.
I think the whole developers-can't-handle-47-EAPIs thing is a red
herring. The fact that there are packages written in Erlang in the
tree doesn't cause me any issues even though I haven't had to do any
work in Erlang. If I ever wanted to maintain such a package then I'd
take the time to learn it as needed. Likewise, if I wanted to
maintain a package that used EAPI joe and I really prefer to work in
EAPI fred, then I'd revise it at my next convenience.
Rich
next prev parent reply other threads:[~2012-10-17 19:01 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
2012-10-17 19:00 ` Rich Freeman [this message]
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=CAGfcS_krHpQd4ocjLV6taPDhde6FgNaHVOgzurJob2Q+safJXQ@mail.gmail.com \
--to=rich0@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