headers
Jose Luis Rivero | 14 Oct 02:00
Favicon

Stabilize ebuilds which use EAPIs only supported by ~arch PMs

Hi all:

Reading a random discussion in our dev mailling list, I came with a
doubt about our new EAPI policy and its procedures. I couldn't find it
documented nor discussed anywhere so I bringing it here.

Supposing that anyone can currently add an ebuild using EAPI-2 under the
testing branch: what are we going to do if an EAPI-2 ebuild (which are
only managed by ~arch package managers) needs to go stable due to some
kind of major reason like security? 

Hypothetical case: foo-1 (eapi-0) marked as stable and foo-2 (eapi-2)
with new features marked as testing. A security problem appears
affecting both. UPSTREAM release foo-3 to solve the security issue.

There are some others sceneries but are not so common as the one presented
could be. Any decent solution for this case?

--

-- 
Jose Luis Rivero <yoswink <at> gentoo.org>
Gentoo/Doc Gentoo/Alpha
Permalink | Reply |
headers
Donnie Berkholz | 14 Oct 02:38
Favicon
Gravatar

Re: Stabilize ebuilds which use EAPIs only supported by ~arch PMs

On 02:03 Tue 14 Oct     , Jose Luis Rivero wrote:
> Hi all:
> 
> Reading a random discussion in our dev mailling list, I came with a
> doubt about our new EAPI policy and its procedures. I couldn't find it
> documented nor discussed anywhere so I bringing it here.
> 
> Supposing that anyone can currently add an ebuild using EAPI-2 under the
> testing branch: what are we going to do if an EAPI-2 ebuild (which are
> only managed by ~arch package managers) needs to go stable due to some
> kind of major reason like security? 
> 
> Hypothetical case: foo-1 (eapi-0) marked as stable and foo-2 (eapi-2)
> with new features marked as testing. A security problem appears
> affecting both. UPSTREAM release foo-3 to solve the security issue.
> 
> There are some others sceneries but are not so common as the one presented
> could be. Any decent solution for this case?

There are only a few obvious ones, you'll have to pick which one you 
like best. Most of the other options basically duplicate these in some 
way or add more work to them for negligible gain:

- Backport the ebuild from EAPI=2 to EAPI=0
- Backport the security patch to the EAPI=0 ebuild
- Stabilize portage quickly

--

-- 
Thanks,
Donnie
(Continue reading)

Permalink | Reply |
headers
Jose Luis Rivero | 14 Oct 10:59
Favicon

Re: Stabilize ebuilds which use EAPIs only supported by ~arch PMs

On Mon, Oct 13, 2008 at 05:38:34PM -0700, Donnie Berkholz wrote:
> On 02:03 Tue 14 Oct     , Jose Luis Rivero wrote:
> > 
> > There are some others sceneries but are not so common as the one presented
> > could be. Any decent solution for this case?
> 
> There are only a few obvious ones, you'll have to pick which one you 
> like best. Most of the other options basically duplicate these in some 
> way or add more work to them for negligible gain:
> 
> - Backport the ebuild from EAPI=2 to EAPI=0

EAPI-2 to EAPI-0 could imply lot of changes (not talking about what is
going to happen when we release new and more feature rich EAPIs), and
changes usually come with bugs. The ebuild is committed directly to stable
implies bugs in stable, which for me is a no-go.

> - Backport the security patch to the EAPI=0 ebuild

Which sometimes is going to be impossible, require lot of work, and we
fall into the risk of bad backported patches when non trivial backport
patches are needed (which turns into buggy patches in the stable branch)

> - Stabilize portage quickly

Most of the times this is not going to be possible. Seems to me that EAPI 
changes are not trivial to PMs and need some kind of decent testing
period. 

Thanks.
(Continue reading)

Permalink | Reply |
headers
Marius Mauch | 14 Oct 18:17
Favicon

Re: Stabilize ebuilds which use EAPIs only supported by ~arch PMs

On Tue, 14 Oct 2008 10:59:39 +0200
Jose Luis Rivero <yoswink <at> gentoo.org> wrote:

> On Mon, Oct 13, 2008 at 05:38:34PM -0700, Donnie Berkholz wrote:
> > On 02:03 Tue 14 Oct     , Jose Luis Rivero wrote:
> > > 
> > > There are some others sceneries but are not so common as the one
> > > presented could be. Any decent solution for this case?
> > 
> > There are only a few obvious ones, you'll have to pick which one
> > you like best. Most of the other options basically duplicate these
> > in some way or add more work to them for negligible gain:
> > 
> > - Backport the ebuild from EAPI=2 to EAPI=0
> 
> EAPI-2 to EAPI-0 could imply lot of changes (not talking about what is
> going to happen when we release new and more feature rich EAPIs), and
> changes usually come with bugs. The ebuild is committed directly to
> stable implies bugs in stable, which for me is a no-go.

Assuming the ebuild changes between foo-1 and foo-2 are mainly due to
the change from EAPI=0 to EAPI=2 (which I'd expect to be true in many
cases) you could just reuse the foo-1 ebuild for foo-3.

If there are major differences between foo-1 and foo-2 not related to
the EAPI change then the maintainer probably didn't want foo-2 to
become stable anytime soon, so it's at least questionable if foo-3
should go straight to stable in the first place.

And adding a new version directly to stable always comes with a risk,
(Continue reading)

Permalink | Reply |
headers
Petteri Räty | 15 Oct 00:34
Favicon

Re: Stabilize ebuilds which use EAPIs only supported by ~arch PMs

Marius Mauch kirjoitti:
> On Tue, 14 Oct 2008 10:59:39 +0200
> Jose Luis Rivero <yoswink <at> gentoo.org> wrote:
> 
>> On Mon, Oct 13, 2008 at 05:38:34PM -0700, Donnie Berkholz wrote:
>>> On 02:03 Tue 14 Oct     , Jose Luis Rivero wrote:
>>>> There are some others sceneries but are not so common as the one
>>>> presented could be. Any decent solution for this case?
>>> There are only a few obvious ones, you'll have to pick which one
>>> you like best. Most of the other options basically duplicate these
>>> in some way or add more work to them for negligible gain:
>>>
>>> - Backport the ebuild from EAPI=2 to EAPI=0
>> EAPI-2 to EAPI-0 could imply lot of changes (not talking about what is
>> going to happen when we release new and more feature rich EAPIs), and
>> changes usually come with bugs. The ebuild is committed directly to
>> stable implies bugs in stable, which for me is a no-go.
> 
> Assuming the ebuild changes between foo-1 and foo-2 are mainly due to
> the change from EAPI=0 to EAPI=2 (which I'd expect to be true in many
> cases) you could just reuse the foo-1 ebuild for foo-3.
> 
> If there are major differences between foo-1 and foo-2 not related to
> the EAPI change then the maintainer probably didn't want foo-2 to
> become stable anytime soon, so it's at least questionable if foo-3
> should go straight to stable in the first place.
> 
> And adding a new version directly to stable always comes with a risk,
> you can't eliminate that completely. It's all about risk assessment,
> and how much work you're willing to do or time you want to spend to
(Continue reading)

Permalink | Reply |
headers
Alec Warner | 15 Oct 03:24
Favicon

Re: Stabilize ebuilds which use EAPIs only supported by ~arch PMs

On Tue, Oct 14, 2008 at 3:34 PM, Petteri Räty <betelgeuse <at> gentoo.org> wrote:
> Marius Mauch kirjoitti:
>> On Tue, 14 Oct 2008 10:59:39 +0200
>> Jose Luis Rivero <yoswink <at> gentoo.org> wrote:
>>
>>> On Mon, Oct 13, 2008 at 05:38:34PM -0700, Donnie Berkholz wrote:
>>>> On 02:03 Tue 14 Oct     , Jose Luis Rivero wrote:
>>>>> There are some others sceneries but are not so common as the one
>>>>> presented could be. Any decent solution for this case?
>>>> There are only a few obvious ones, you'll have to pick which one
>>>> you like best. Most of the other options basically duplicate these
>>>> in some way or add more work to them for negligible gain:
>>>>
>>>> - Backport the ebuild from EAPI=2 to EAPI=0
>>> EAPI-2 to EAPI-0 could imply lot of changes (not talking about what is
>>> going to happen when we release new and more feature rich EAPIs), and
>>> changes usually come with bugs. The ebuild is committed directly to
>>> stable implies bugs in stable, which for me is a no-go.
>>
>> Assuming the ebuild changes between foo-1 and foo-2 are mainly due to
>> the change from EAPI=0 to EAPI=2 (which I'd expect to be true in many
>> cases) you could just reuse the foo-1 ebuild for foo-3.
>>
>> If there are major differences between foo-1 and foo-2 not related to
>> the EAPI change then the maintainer probably didn't want foo-2 to
>> become stable anytime soon, so it's at least questionable if foo-3
>> should go straight to stable in the first place.
>>
>> And adding a new version directly to stable always comes with a risk,
>> you can't eliminate that completely. It's all about risk assessment,
(Continue reading)

Permalink | Reply |
headers
Santiago M. Mola | 15 Oct 12:30
Favicon

Re: Stabilize ebuilds which use EAPIs only supported by ~arch PMs

El mar, 14-10-2008 a las 18:24 -0700, Alec Warner escribió:
> On Tue, Oct 14, 2008 at 3:34 PM, Petteri Räty <betelgeuse <at> gentoo.org> 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.
> 

If you're thinking about having two equal versions with different EAPIs,
that's not allowed by GLEP 55:

"Note that it is still not permitted to have more than one ebuild with
equal category, package name, and version. Although it would have the
advantage of allowing authors to provide backwards compatible ebuilds,
it would introduce problems too. The first is the requirement to have
strict EAPI ordering, the second is ensuring that all the ebuilds for a
single category/package-version are equivalent, i.e. installing any of
them has exactly the same effect on a given system."

Regards,
--

-- 
Santiago Moisés Mola
Jabber: cooldwind <at> gmail.com | GPG: AAD203B5
Permalink | Reply |
headers
Steve Long | 15 Oct 12:50

Re: Stabilize ebuilds which use EAPIs only supported by ~arch PMs

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.
(Continue reading)

Permalink | Reply |
headers
Jose Luis Rivero | 16 Oct 14:50
Favicon

Re: Stabilize ebuilds which use EAPIs only supported by ~arch PMs

On Tue, Oct 14, 2008 at 06:17:12PM +0200, Marius Mauch wrote:
> On Tue, 14 Oct 2008 10:59:39 +0200
> Jose Luis Rivero <yoswink <at> gentoo.org> wrote:
> > 
> > EAPI-2 to EAPI-0 could imply lot of changes (not talking about what is
> > going to happen when we release new and more feature rich EAPIs), and
> > changes usually come with bugs. The ebuild is committed directly to
> > stable implies bugs in stable, which for me is a no-go.
> 
> Assuming the ebuild changes between foo-1 and foo-2 are mainly due to
> the change from EAPI=0 to EAPI=2 (which I'd expect to be true in many
> cases) you could just reuse the foo-1 ebuild for foo-3.
> 
> If there are major differences between foo-1 and foo-2 not related to
> the EAPI change then the maintainer probably didn't want foo-2 to
> become stable anytime soon, so it's at least questionable if foo-3
> should go straight to stable in the first place.

I was talking about this case, were foo-2 is in testing and is not ready
for stable. It's not questionable to go directly to stable if security is
involved in the process.

> And adding a new version directly to stable always comes with a risk,
> you can't eliminate that completely. It's all about risk assessment,
> and how much work you're willing to do or time you want to spend to
> minimize the risk.

Agree. The question bringing here is: how can we minimize the risk if
this situation appear, where we have an EAPI change between ebuilds in 
stable and testing branch and EAPI in testing can only be managed by
(Continue reading)

Permalink | Reply |
headers
Christian Faulhammer | 14 Oct 02:39
Favicon

Re: Stabilize ebuilds which use EAPIs only supported by ~arch PMs

Hi,

Jose Luis Rivero <yoswink <at> gentoo.org>:

> Hypothetical case: foo-1 (eapi-0) marked as stable and foo-2 (eapi-2)
> with new features marked as testing. A security problem appears
> affecting both. UPSTREAM release foo-3 to solve the security issue.

 Backport the fix or create an EAPI=0 ebuild, as the package manager
will mask EAPIs it cannot understand, so you cannot emerge it anyway.

V-Li

--

-- 
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://www.faulhammer.org/>
Permalink | Reply |

Gmane