Re: [gentoo-dev] Stabilize ebuilds which use EAPIs only supported by ~arch PMs

2008-10-15 Thread Santiago M. Mola
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] | GPG: AAD203B5


signature.asc
Description: Esta parte del mensaje está firmada	digitalmente


Re: [gentoo-dev] Stabilize ebuilds which use EAPIs only supported by ~arch PMs

2008-10-14 Thread Jose Luis Rivero
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.

-- 
Jose Luis Rivero [EMAIL PROTECTED]
Gentoo/Doc Gentoo/Alpha




Re: [gentoo-dev] Stabilize ebuilds which use EAPIs only supported by ~arch PMs

2008-10-14 Thread Marius Mauch
On Tue, 14 Oct 2008 10:59:39 +0200
Jose Luis Rivero [EMAIL PROTECTED] 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
minimize the risk.

  - 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)

And sometimes it's a very viable option when patches are provided by
upstream.

In the end at least one of the above solutions should work in
almost every case. It might sometimes cause a bit more work than a bump
that doesn't involve any EAPI changes, but that's life.
If you have a real case where both suggested solutions aren't
realistic I'd like to hear about it, otherwise I think we're wasting
time making up solutions for a non-existant problem

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.


signature.asc
Description: PGP signature


Re: [gentoo-dev] Stabilize ebuilds which use EAPIs only supported by ~arch PMs

2008-10-14 Thread Petteri Räty
Marius Mauch kirjoitti:
 On Tue, 14 Oct 2008 10:59:39 +0200
 Jose Luis Rivero [EMAIL PROTECTED] 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
 minimize the risk.
 

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.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Stabilize ebuilds which use EAPIs only supported by ~arch PMs

2008-10-14 Thread Alec Warner
On Tue, Oct 14, 2008 at 3:34 PM, Petteri Räty [EMAIL PROTECTED] wrote:
 Marius Mauch kirjoitti:
 On Tue, 14 Oct 2008 10:59:39 +0200
 Jose Luis Rivero [EMAIL PROTECTED] 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
 minimize the risk.


 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.

[1] http://www.gentoo.org/proj/en/glep/glep-0055.html


 Regards,
 Petteri




[gentoo-dev] Stabilize ebuilds which use EAPIs only supported by ~arch PMs

2008-10-13 Thread Jose Luis Rivero
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 [EMAIL PROTECTED]
Gentoo/Doc Gentoo/Alpha




Re: [gentoo-dev] Stabilize ebuilds which use EAPIs only supported by ~arch PMs

2008-10-13 Thread Donnie Berkholz
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

Donnie Berkholz
Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com


pgpPRRDlntCoO.pgp
Description: PGP signature