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: Fri, 19 Oct 2012 21:53:18 +0200 [thread overview]
Message-ID: <1350676398.12879.50.camel@belkin4> (raw)
In-Reply-To: <5081AD7B.1040100@gentoo.org>
[-- Attachment #1: Type: text/plain, Size: 1861 bytes --]
El vie, 19-10-2012 a las 21:43 +0200, Thomas Sachau escribió:
> Pacho Ramos schrieb:
> > I volunteer to do whatever conversions you want for every ebuild I find
> > if I have time... what prevents me from doing it is to commit that
> > changes to ebuilds not maintained by me and not knowing if developers
> > agree on using latest eapi if possible. A more general solution (or
> > policy) needs to be worked as, otherwise, tree won't be moved to latest
> > eapi ever because we would need to:
> > - Periodically send bugs + patches
> > - Ask for permission to commit
> >
> > And that for every eapi bump
> >
>
> Either an ebuild has a responsive maintainer, which you can ask friendly
> to bump the EAPI because of feature X you would like to use or there is
> no maintainer, in which case you are free to touch/bump or last rite the
> ebuild.
>
> So i still dont see any need or requirement for a policy to
> force/require all devs to always use or switch to the latest avaidable
> EAPI. As already written in this thread, it would just mean less new
> ebuilds and less version bumps with such a policy. And i also prefer
> more work done with older EAPI versions around then less ebuilds/new
> versions with latest EAPI.
>
Seriously, what people is still having problems with handling eapi4? If
there are doubts about its usage, they should be asked and resolved
instead of ignored keeping ebuilds with older eapis. The only eapi that
probably adds no advantage for a lot of ebuilds is eapi3, but that is
not the case for eapi4 for example, that includes changes that should be
incorporated by most packages in the tree, some of them introduced by it
and others inherited from older eapis.
What is the advantage of using eapi2 over eapi4 for example? What "hard
to learn" change was included in eapi4 over eapi2?
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
next prev parent reply other threads:[~2012-10-19 19:54 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
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 [this message]
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=1350676398.12879.50.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