| 1 |
Alec Warner wrote: |
| 2 |
> Petteri Räty wrote: |
| 3 |
>> There's no need to commit straight to stable. Just make two different |
| 4 |
>> new revisions for each EAPI. Then the arch teams can test it like usual. |
| 5 |
> |
| 6 |
> Aha a perfect canidate use case for GLEP 55[1] that fends off 'why are |
| 7 |
> there multiple versions of the same package' questions and |
| 8 |
> complexities. |
| 9 |
> |
| 10 |
Hmm AFAICT there isn't any need to do put it in the filename, as the package |
| 11 |
manager will simply ignore an EAPI (which comes from the rsync'ed cache for |
| 12 |
the Gentoo tree) it doesn't know. Additionally all the manglers deal with |
| 13 |
EAPI 0-2 fine afaik. If it's solely about the different rev ids, I think |
| 14 |
it's a bit of a red herring; anyone confused could simply be told "this is |
| 15 |
a security fix" if they cared to ask (or look in the Changelog) and these |
| 16 |
aren't exactly going to be all over the tree. Could be masked "for |
| 17 |
arch-testing [security fix]" and then the relevant fixed older version put |
| 18 |
into the tree, as now. |
| 19 |
|
| 20 |
Personally I'd rather remove the restriction and allow ebuilds to work with |
| 21 |
more than one EAPI, as explicitly declared, instead of having to write two |
| 22 |
revisions. One could then also inherit from a security eclass to make it |
| 23 |
clear to anyone reading the ebuild what was happening (which would also |
| 24 |
work for two different revs with variant EAPIs ofc.) |
| 25 |
|
| 26 |
Whatever, I don't think this use-case is anywhere near enough to justify the |
| 27 |
massive intrusion that GLEP55 is. The versioning thing brought up before is |
| 28 |
best done via debian-style epochs, if anyone really wants to fix that. |
Archives