Alec Warner wrote:
> Petteri Räty wrote:
>> There's no need to commit straight to stable. Just make two different
>> new revisions for each EAPI. Then the arch teams can test it like usual.
> 
> Aha a perfect canidate use case for GLEP 55[1] that fends off 'why are
> there multiple versions of the same package' questions and
> complexities.
>
Hmm AFAICT there isn't any need to do put it in the filename, as the package
manager will simply ignore an EAPI (which comes from the rsync'ed cache for
the Gentoo tree) it doesn't know. Additionally all the manglers deal with
EAPI 0-2 fine afaik. If it's solely about the different rev ids, I think
it's a bit of a red herring; anyone confused could simply be told "this is
a security fix" if they cared to ask (or look in the Changelog) and these
aren't exactly going to be all over the tree. Could be masked "for
arch-testing [security fix]" and then the relevant fixed older version put
into the tree, as now.

Personally I'd rather remove the restriction and allow ebuilds to work with
more than one EAPI, as explicitly declared, instead of having to write two
revisions. One could then also inherit from a security eclass to make it
clear to anyone reading the ebuild what was happening (which would also
work for two different revs with variant EAPIs ofc.)

Whatever, I don't think this use-case is anywhere near enough to justify the
massive intrusion that GLEP55 is. The versioning thing brought up before is
best done via debian-style epochs, if anyone really wants to fix that.



Reply via email to