| 1 |
On Mon, 10 Feb 2014 08:34:00 -0500 |
| 2 |
Rich Freeman <rich0@g.o> wrote: |
| 3 |
|
| 4 |
> On Mon, Feb 10, 2014 at 7:43 AM, Patrick Lauer <patrick@g.o> |
| 5 |
> wrote: |
| 6 |
> > Adding EAPI 1 and 2 ebuilds is forbidden. (repoman-fatal) |
| 7 |
> |
| 8 |
> Does "adding" in this case include revbumps? |
| 9 |
|
| 10 |
Yes; though, we kind of expect rev bumps to include multiple fixes if |
| 11 |
possible, not just a fix for a particular bug. It is indeed kind of up |
| 12 |
to the maintainer if he wants to include trivial fixes like EAPI bumps |
| 13 |
and what not; though, it can be really fun when you add patches to |
| 14 |
src_prepare in an EAPI that doesn't support src_prepare yet... :) |
| 15 |
|
| 16 |
> > More than two supported EAPIs is an unneeded burden on developers. |
| 17 |
> |
| 18 |
> Is this really a generally held belief? I don't find it a burden that |
| 19 |
> ebuilds in the tree may use various EAPIs. I could see how they make |
| 20 |
> scripted mass-updates to ebuilds more difficult, though I'm not sure |
| 21 |
> how much of an issue this is in practice. |
| 22 |
> |
| 23 |
> I could also see how supporting many EAPIs could be a burden on |
| 24 |
> package managers, but if that is a concern I'd be interested in |
| 25 |
> hearing from these maintainers. |
| 26 |
> |
| 27 |
> My sense is that deprecating probably makes sense, but banning should |
| 28 |
> only be done if in reaction to a particular problem. Repoman warnings |
| 29 |
> call attention to the issue so that the maintainer is aware and can |
| 30 |
> take the appropriate action, but without restricting their actions. |
| 31 |
> |
| 32 |
> Now, if people are actually impacted by all the EAPIs I don't mind |
| 33 |
> pushing harder to get rid of some. |
| 34 |
|
| 35 |
A lot of this is more of a future proof approach than to address an |
| 36 |
actual practical problem; the ~5 or so cases we've got to support in |
| 37 |
PMs, which are actually often just ~2 or ~3, aren't really a burden as |
| 38 |
it stands now. But once that gets to the ~10 cases, which boils down to |
| 39 |
often like maybe ~4 to ~6 cases; it becomes a bit more bloated up to a |
| 40 |
point you really start yelling at code cruft, but we're still far from |
| 41 |
as there are less often PMS releases these days. |
| 42 |
|
| 43 |
Well, some of us also see it as code cruft in the Portage tree; also in |
| 44 |
a way that is growing as we get more releases of the PMS, this will |
| 45 |
probably not ever really bother maintainers (unless we expect them to |
| 46 |
know how older EAPIs were by heart, this is comparable to how web |
| 47 |
developers need to account for older versions of browsers) but it really |
| 48 |
could start to bother those whom look over the whole Portage tree. |
| 49 |
|
| 50 |
-- |
| 51 |
With kind regards, |
| 52 |
|
| 53 |
Tom Wijsman (TomWij) |
| 54 |
Gentoo Developer |
| 55 |
|
| 56 |
E-mail address : TomWij@g.o |
| 57 |
GPG Public Key : 6D34E57D |
| 58 |
GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D |
Archives