Re: [gentoo-dev] [RFC] Tightening EAPI rules

[Tom Wijsman <TomWij@gentoo.org>]

On Mon, 10 Feb 2014 08:34:00 -0500
Rich Freeman <rich0@gentoo.org> wrote:

> On Mon, Feb 10, 2014 at 7:43 AM, Patrick Lauer <patrick@gentoo.org>
> wrote:
> > Adding EAPI 1 and 2 ebuilds is forbidden. (repoman-fatal)
> 
> Does "adding" in this case include revbumps?

Yes; though, we kind of expect rev bumps to include multiple fixes if
possible, not just a fix for a particular bug. It is indeed kind of up
to the maintainer if he wants to include trivial fixes like EAPI bumps
and what not; though, it can be really fun when you add patches to
src_prepare in an EAPI that doesn't support src_prepare yet... :)

> > More than two supported EAPIs is an unneeded burden on developers.
> 
> Is this really a generally held belief?  I don't find it a burden that
> ebuilds in the tree may use various EAPIs.  I could see how they make
> scripted mass-updates to ebuilds more difficult, though I'm not sure
> how much of an issue this is in practice.
> 
> I could also see how supporting many EAPIs could be a burden on
> package managers, but if that is a concern I'd be interested in
> hearing from these maintainers.
> 
> My sense is that deprecating probably makes sense, but banning should
> only be done if in reaction to a particular problem.  Repoman warnings
> call attention to the issue so that the maintainer is aware and can
> take the appropriate action, but without restricting their actions.
> 
> Now, if people are actually impacted by all the EAPIs I don't mind
> pushing harder to get rid of some.

A lot of this is more of a future proof approach than to address an
actual practical problem; the ~5 or so cases we've got to support in
PMs, which are actually often just ~2 or ~3, aren't really a burden as
it stands now. But once that gets to the ~10 cases, which boils down to
often like maybe ~4 to ~6 cases; it becomes a bit more bloated up to a
point you really start yelling at code cruft, but we're still far from
as there are less often PMS releases these days.

Well, some of us also see it as code cruft in the Portage tree; also in
a way that is growing as we get more releases of the PMS, this will
probably not ever really bother maintainers (unless we expect them to
know how older EAPIs were by heart, this is comparable to how web
developers need to account for older versions of browsers) but it really
could start to bother those whom look over the whole Portage tree.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D