[gentoo-dev] EAPI Changes

[gentoo-dev] EAPI Changes

[William Hubbs]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, May 15, 2009 at 03:49:51AM -0700, Robin H. Johnson wrote:
> On Fri, May 15, 2009 at 10:47:24AM +0200, Tiziano M?ller wrote:
> > Thanks Robin for finally pushing this in the tree, just didn't find the
> > time to.
> > 
> > Maybe it's a good time to emphasize this: Keep in mind that changing the
> > EAPI in an ebuild requires a revision bump (including reset to unstable
> > keywords, etc.).
> That's going to cause a large problem.
> 
> The entire point is that the STABLE ebuilds need to be changed,
> otherwise they will try to depend on the libusb-1 series (and fail
> dismally).
> 
> For switching from EAPI0 to EAPI1, if the ebuild still compiles fine,
> then I see no reason that a slot dep change cannot be just put in with
> the EAPI change. (The same cannot be said for EAPIx -> EAPI2, as further
> changes are needed for that case).
 
 As far as I know, the only time you need to do a rev bump and reset to
 unstable is if you change the files that are installed by the package.

 So, as far as I know, unless you are migrating to an EAPI that is not
 stable or changing the files that are installed by the package, it is
 not necessary to do a rev bump just for changing the EAPI as long as
 you make sure that the ebuild emerges fine under the new EAPI.

- -- 
William Hubbs
gentoo accessibility team lead
williamh@gentoo.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkoNgNcACgkQblQW9DDEZTgorACdGfiXec4JUIC3UJDL/sGctbEi
FpwAn3UxUOjxuQUxl0w5S95M271+306Q
=jinO
-----END PGP SIGNATURE-----

Re: [gentoo-dev] EAPI Changes

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 1577 bytes --]

William Hubbs wrote:
> On Fri, May 15, 2009 at 03:49:51AM -0700, Robin H. Johnson wrote:
>> On Fri, May 15, 2009 at 10:47:24AM +0200, Tiziano M?ller wrote:
>>> Thanks Robin for finally pushing this in the tree, just didn't find the
>>> time to.
>>>
>>> Maybe it's a good time to emphasize this: Keep in mind that changing the
>>> EAPI in an ebuild requires a revision bump (including reset to unstable
>>> keywords, etc.).
>> That's going to cause a large problem.
> 
>> The entire point is that the STABLE ebuilds need to be changed,
>> otherwise they will try to depend on the libusb-1 series (and fail
>> dismally).
> 
>> For switching from EAPI0 to EAPI1, if the ebuild still compiles fine,
>> then I see no reason that a slot dep change cannot be just put in with
>> the EAPI change. (The same cannot be said for EAPIx -> EAPI2, as further
>> changes are needed for that case).
>  
>  As far as I know, the only time you need to do a rev bump and reset to
>  unstable is if you change the files that are installed by the package.
> 
>  So, as far as I know, unless you are migrating to an EAPI that is not
>  stable or changing the files that are installed by the package, it is
>  not necessary to do a rev bump just for changing the EAPI as long as
>  you make sure that the ebuild emerges fine under the new EAPI.
> 

Indeed there's no problem switching EAPIs as long as a stable Portage
supports the EAPI you are migrating to. Portage was buggy with this when
EAPI 2 was introduced but that has since been fixed.

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 261 bytes --]

Re: [gentoo-dev] EAPI Changes

[Tiziano Müller]

[-- Attachment #1: Type: text/plain, Size: 3054 bytes --]

Am Freitag, den 15.05.2009, 23:30 +0300 schrieb Petteri Räty:
> William Hubbs wrote:
> > On Fri, May 15, 2009 at 03:49:51AM -0700, Robin H. Johnson wrote:
> >> On Fri, May 15, 2009 at 10:47:24AM +0200, Tiziano M?ller wrote:
> >>> Thanks Robin for finally pushing this in the tree, just didn't find the
> >>> time to.
> >>>
> >>> Maybe it's a good time to emphasize this: Keep in mind that changing the
> >>> EAPI in an ebuild requires a revision bump (including reset to unstable
> >>> keywords, etc.).
> >> That's going to cause a large problem.
> > 
> >> The entire point is that the STABLE ebuilds need to be changed,
> >> otherwise they will try to depend on the libusb-1 series (and fail
> >> dismally).
> > 
> >> For switching from EAPI0 to EAPI1, if the ebuild still compiles fine,
> >> then I see no reason that a slot dep change cannot be just put in with
> >> the EAPI change. (The same cannot be said for EAPIx -> EAPI2, as further
> >> changes are needed for that case).
> >  
> >  As far as I know, the only time you need to do a rev bump and reset to
> >  unstable is if you change the files that are installed by the package.
> > 
> >  So, as far as I know, unless you are migrating to an EAPI that is not
> >  stable or changing the files that are installed by the package, it is
> >  not necessary to do a rev bump just for changing the EAPI as long as
> >  you make sure that the ebuild emerges fine under the new EAPI.
> > 
> 
> Indeed there's no problem switching EAPIs as long as a stable Portage
> supports the EAPI you are migrating to. Portage was buggy with this when
> EAPI 2 was introduced but that has since been fixed.

Wrong. For example:
- stuff like docompress may change the content being installed depending
on the package manager
- --disable-static (maybe in a later EAPI) changes content
- slot-dep-operators change the rdepend of installed packages, so it
changes how the package manager has to handle reverse packages on
uninstall (in EAPI 3)

On the other hand you also have to make sure you have a stable portage
for a time long enough so mostly everyone has it installed. Otherwise
you could break users systems pretty badly depending on the packages.
And Arch-Teams usually do a pretty good job in catching such cases.

And we also always said that a rev bump should be done on non trivial
changes or non-build-fixes and changing the EAPI is technical seen
mostly a non-trivial change.

Do we want to document the following? (do we have already?)
- When is it allowed to use an EAPI in the tree (given as offset to the
release of portage supporting that eapi)
- When is it allowed to use an EAPI in the stable tree (given as offset
of when a portage version supporting that EAPI got stable)

Cheers,
Tiziano


-- 
Tiziano Müller
Gentoo Linux Developer, Council Member
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-zero@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30

[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] EAPI Changes

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 3604 bytes --]

Tiziano Müller wrote:
> Am Freitag, den 15.05.2009, 23:30 +0300 schrieb Petteri Räty:
>> William Hubbs wrote:
>>> On Fri, May 15, 2009 at 03:49:51AM -0700, Robin H. Johnson wrote:
>>>> On Fri, May 15, 2009 at 10:47:24AM +0200, Tiziano M?ller wrote:
>>>>> Thanks Robin for finally pushing this in the tree, just didn't find the
>>>>> time to.
>>>>>
>>>>> Maybe it's a good time to emphasize this: Keep in mind that changing the
>>>>> EAPI in an ebuild requires a revision bump (including reset to unstable
>>>>> keywords, etc.).
>>>> That's going to cause a large problem.
>>>> The entire point is that the STABLE ebuilds need to be changed,
>>>> otherwise they will try to depend on the libusb-1 series (and fail
>>>> dismally).
>>>> For switching from EAPI0 to EAPI1, if the ebuild still compiles fine,
>>>> then I see no reason that a slot dep change cannot be just put in with
>>>> the EAPI change. (The same cannot be said for EAPIx -> EAPI2, as further
>>>> changes are needed for that case).
>>>  
>>>  As far as I know, the only time you need to do a rev bump and reset to
>>>  unstable is if you change the files that are installed by the package.
>>>
>>>  So, as far as I know, unless you are migrating to an EAPI that is not
>>>  stable or changing the files that are installed by the package, it is
>>>  not necessary to do a rev bump just for changing the EAPI as long as
>>>  you make sure that the ebuild emerges fine under the new EAPI.
>>>
>> Indeed there's no problem switching EAPIs as long as a stable Portage
>> supports the EAPI you are migrating to. Portage was buggy with this when
>> EAPI 2 was introduced but that has since been fixed.
> 
> Wrong. For example:
> - stuff like docompress may change the content being installed depending
> on the package manager
> - --disable-static (maybe in a later EAPI) changes content
> - slot-dep-operators change the rdepend of installed packages, so it
> changes how the package manager has to handle reverse packages on
> uninstall (in EAPI 3)
> 

Switching EAPIs in my mind means taking care it works with new EAPIs.
Why switch in the first place if you aren't making modifications to the
ebuild?

> On the other hand you also have to make sure you have a stable portage
> for a time long enough so mostly everyone has it installed. Otherwise
> you could break users systems pretty badly depending on the packages.
> And Arch-Teams usually do a pretty good job in catching such cases.
> 

How would this breakage happen? The ebuild in the vdb still has the old
EAPI.

> And we also always said that a rev bump should be done on non trivial
> changes or non-build-fixes and changing the EAPI is technical seen
> mostly a non-trivial change.
> 

Switching between EAPI 0 and 1 for example is quite trivial. In Java
ebuilds we should always use slot deps because jars get installed to a
SLOT dependent path. I doubt our users would want to see us revision
bumping our ebuilds for that.

> Do we want to document the following? (do we have already?)
> - When is it allowed to use an EAPI in the tree (given as offset to the
> release of portage supporting that eapi)
> - When is it allowed to use an EAPI in the stable tree (given as offset
> of when a portage version supporting that EAPI got stable)
> 

Currently:
1. Usage of an EAPI in the tree is allowed after council gives the OK.
2. When the Portage version supporting it goes stable

If you want please check devmanual and file a bug if it needs
updating/new info regarding this.

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 261 bytes --]

Re: [gentoo-dev] EAPI Changes

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 676 bytes --]

On Sat, 16 May 2009 02:31:45 +0300
Petteri Räty <betelgeuse@gentoo.org> wrote:
> > On the other hand you also have to make sure you have a stable
> > portage for a time long enough so mostly everyone has it installed.
> > Otherwise you could break users systems pretty badly depending on
> > the packages. And Arch-Teams usually do a pretty good job in
> > catching such cases.
> 
> How would this breakage happen? The ebuild in the vdb still has the
> old EAPI.

Portage likes to use metadata from the tree version of things even if
there's also a version installed. This is a major nuisance, but is
unfortunately considered a feature.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] Re: EAPI Changes

[Duncan]

Petteri Räty <betelgeuse@gentoo.org> posted 4A0DD0ED.1070108@gentoo.org,
excerpted below, on  Fri, 15 May 2009 23:30:37 +0300:

> Indeed there's no problem switching EAPIs as long as a stable Portage
> supports the EAPI you are migrating to. Portage was buggy with this when
> EAPI 2 was introduced but that has since been fixed.

The case at hand is EAPI-0 > EAPI-1.  I've no opinion there.

However, just this last week I tracked down and provided a patch for an 
EAPI-0 > EAPI-2 conversion related bug[1] in an existing previously 
working ebuild, converted without a bump.  It was and remained ~arch so 
users should have been prepared to cope, but a bump would have been nice 
and it would have been a SERIOUS mistake to try to do that as stable.

So I agree with the earlier opinion that while it may not matter for 
EAPI-0 > EAPI-1, as a general policy and certainly for conversions to 
EAPI-2 and probably EAPI-3, a revision bump and ~arch keywording, thus 
forcing the package thru a new stabilizing process, should be strongly 
recommended at minimum -- enough that a tree change to dozens of stable 
ebuilds such as is being discussed simply wouldn't be possible, without 
assuming a bump and new stabilization process, thus, effectively 
requiring 60-days working minimum process time (30 no-bugs, 30 stable-
keywording).

[1] Bug #269691, kaffeine
plain:    http://bugs.gentoo.org/show_bug.cgi?id=269691
secure:  https://bugs.gentoo.org/show_bug.cgi?id=269691

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: EAPI Changes

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 1145 bytes --]

Duncan wrote:
> Petteri Räty <betelgeuse@gentoo.org> posted 4A0DD0ED.1070108@gentoo.org,
> excerpted below, on  Fri, 15 May 2009 23:30:37 +0300:
> 
>> Indeed there's no problem switching EAPIs as long as a stable Portage
>> supports the EAPI you are migrating to. Portage was buggy with this when
>> EAPI 2 was introduced but that has since been fixed.
> 
> The case at hand is EAPI-0 > EAPI-1.  I've no opinion there.
> 
> However, just this last week I tracked down and provided a patch for an 
> EAPI-0 > EAPI-2 conversion related bug[1] in an existing previously 
> working ebuild, converted without a bump.  It was and remained ~arch so 
> users should have been prepared to cope, but a bump would have been nice 
> and it would have been a SERIOUS mistake to try to do that as stable.
> 

Well even with EAPI 2 it's quite hard to introduce breakage if you
actually test the changes. If you don't do proper testing, then the only
way to prevent breakage is to kick that developer out, no policy is
going to help. (I am not implying we should start kicking people out for
small mistakes though)

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 261 bytes --]

Re: [gentoo-dev] EAPI Changes

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 894 bytes --]

Ciaran McCreesh wrote:
> On Sat, 16 May 2009 02:31:45 +0300
> Petteri Räty <betelgeuse@gentoo.org> wrote:
>>> On the other hand you also have to make sure you have a stable
>>> portage for a time long enough so mostly everyone has it installed.
>>> Otherwise you could break users systems pretty badly depending on
>>> the packages. And Arch-Teams usually do a pretty good job in
>>> catching such cases.
>> How would this breakage happen? The ebuild in the vdb still has the
>> old EAPI.
> 
> Portage likes to use metadata from the tree version of things even if
> there's also a version installed. This is a major nuisance, but is
> unfortunately considered a feature.
> 

I think the question here is that what Portage does when there's a newer
EAPI in the tree version that Portage does not yet support but there's a
supported version in the vdb.

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 261 bytes --]

[gentoo-dev] Re: EAPI Changes

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 2631 bytes --]

On Fri, 15 May 2009 23:31:25 +0200
Tiziano Müller <dev-zero@gentoo.org> wrote:

> Wrong. For example:
> - stuff like docompress may change the content being installed depending
> on the package manager
> - --disable-static (maybe in a later EAPI) changes content
> - slot-dep-operators change the rdepend of installed packages, so it
> changes how the package manager has to handle reverse packages on
> uninstall (in EAPI 3)

None of which are a problem when changing the EAPI from 0 to 1, which is the
situation here. The first two examples fall under the currently established
guideline of revbumping when content changes (and I emphasize guideline).  I
don't see how the third example is any different than adding or removing
dependencies, which also does not require a revbump.  So I'd argue that an
EAPI change does not require a revision bump in and of itself.  That's not to
say it shouldn't be done if the situation allows, or you have any doubts, or
just because you want to. But unconditionally putting an ebuild through full
~arch to stable cycle because you added a simple SLOT dependency or a + to a
USE flag is bureaucratic nonsense.

> And we also always said that a rev bump should be done on non trivial
> changes or non-build-fixes and changing the EAPI is technical seen
> mostly a non-trivial change.

As above, it depends on the situation.  0 -> 1 is a trivial change.

> Do we want to document the following? (do we have already?)
> - When is it allowed to use an EAPI in the tree (given as offset to the
> release of portage supporting that eapi)
> - When is it allowed to use an EAPI in the stable tree (given as offset
> of when a portage version supporting that EAPI got stable)

As soon as a version of portage supporting that EAPI is available.

This is the entire point of the EAPI, that we don't have to wait X amount of
time before using new features.  If the user hasn't updated portage yet, they
simply won't see ebuilds which use the new EAPI.

We may want to document a suggested waiting time before removing ebuilds
using older EAPI's.  For example, should we always keep an EAPI 0 ebuild in
stable as a fallback?  Or if the user tries to install or update a package
where all versions are masked by EAPI, should (does?) portage suggest updating
itself?  How long should we keep core system packages at earlier EAPI's?


-- 
gcc-porting,                                      by design, by neglect
treecleaner,                              for a fact or just for effect
wxwidgets @ gentoo     EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: EAPI Changes

[Tiziano Müller]

[-- Attachment #1: Type: text/plain, Size: 3548 bytes --]

Am Sonntag, den 17.05.2009, 11:11 -0600 schrieb Ryan Hill:
> On Fri, 15 May 2009 23:31:25 +0200
> Tiziano Müller <dev-zero@gentoo.org> wrote:
> 
> > Wrong. For example:
> > - stuff like docompress may change the content being installed depending
> > on the package manager
> > - --disable-static (maybe in a later EAPI) changes content
> > - slot-dep-operators change the rdepend of installed packages, so it
> > changes how the package manager has to handle reverse packages on
> > uninstall (in EAPI 3)
> 
> None of which are a problem when changing the EAPI from 0 to 1, which is the
> situation here. The first two examples fall under the currently established
> guideline of revbumping when content changes (and I emphasize guideline).  I
> don't see how the third example is any different than adding or removing
> dependencies, which also does not require a revbump.
Which is mostly wrong as well since a change in dependency means that
the currently installed stuff may break if a package (the new dependency
for example) gets removed and since the package you changed does not
reference it, it gets broken (for example if you had a magic dep before
and add it now as an explicit dep). So, unless you're doing a pkgmove
it's a dangerous thing since the PM can't reliably track reverse deps
when doing uninstalls since it has to use the vdb entry for that,
doesn't it?

>   So I'd argue that an
> EAPI change does not require a revision bump in and of itself.
EAPI may imply a decent implicit change to the ebuild and therefore
needs a rev-bump as per the manual.

>   That's not to
> say it shouldn't be done if the situation allows, or you have any doubts, or
> just because you want to. But unconditionally putting an ebuild through full
> ~arch to stable cycle because you added a simple SLOT dependency or a + to a
> USE flag is bureaucratic nonsense.
> 
> > And we also always said that a rev bump should be done on non trivial
> > changes or non-build-fixes and changing the EAPI is technical seen
> > mostly a non-trivial change.
> 
> As above, it depends on the situation.  0 -> 1 is a trivial change.
> 
> > Do we want to document the following? (do we have already?)
> > - When is it allowed to use an EAPI in the tree (given as offset to the
> > release of portage supporting that eapi)
> > - When is it allowed to use an EAPI in the stable tree (given as offset
> > of when a portage version supporting that EAPI got stable)
> 
> As soon as a version of portage supporting that EAPI is available.
And how much time a portage with a new EAPI got stabled?
(see for example early python eapi bumps)

> 
> This is the entire point of the EAPI, that we don't have to wait X amount of
> time before using new features.  If the user hasn't updated portage yet, they
> simply won't see ebuilds which use the new EAPI.
> 
> We may want to document a suggested waiting time before removing ebuilds
> using older EAPI's.  For example, should we always keep an EAPI 0 ebuild in
> stable as a fallback?  Or if the user tries to install or update a package
> where all versions are masked by EAPI, should (does?) portage suggest updating
> itself?
It would maybe suggest to update to an unstable version of portage, not
so good then?

-- 
Tiziano Müller
Gentoo Linux Developer, Council Member
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-zero@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30

[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] Re: EAPI Changes

[Duncan]

Ryan Hill <dirtyepic@gentoo.org> posted
20090517111152.133c7280@halo.dirtyepic.sk.ca, excerpted below, on  Sun, 17
May 2009 11:11:52 -0600:

>> Do we want to document the following? (do we have already?) - When is
>> it allowed to use an EAPI in the tree (given as offset to the release
>> of portage supporting that eapi) - When is it allowed to use an EAPI in
>> the stable tree (given as offset of when a portage version supporting
>> that EAPI got stable)
> 
> As soon as a version of portage supporting that EAPI is available.

That's a dangerous position to take.  See "experimental" EAPIs for 
instance, sometimes temporarily supported by portage, but NOT for use in 
the tree.

But I think you knew that and simply made some assumptions with the 
statement that not all readers may have.

> This is the entire point of the EAPI, that we don't have to wait X
> amount of time before using new features.  If the user hasn't updated
> portage yet, they simply won't see ebuilds which use the new EAPI.

Agreed.

As I've seen it stated, an EAPI must be approved by council before 
ebuilds using it are allowed in-tree at all.  Procedure there seems to be 
that final approval does not occur until all three PMs support it.  (See 
EAPI-3, now preapproved, but conditional on feature implementation, with 
removal of some feature or other possible before final approval if not 
all PMs support it in a timely manner.)

That's for in-tree.  For arch-stable, the qualifier is no longer all 
three PMs, but only portage, as the default PM at this time.  When a 
portage version supporting the approved EAPI is stable, ebuilds using it 
may be stabilized as well.

But I agree that the point of EAPIs is to avoid delay, and that once an 
EAPI has final approval (as I said, itself conditional on working 
implementation in ~ versions of the PMs), there's no need to wait longer 
to put it in-tree as masked or unstable.  And for stable, once a portage 
with the approved EAPI goes stable, so can packages using it.

That's my understanding of council and QA policy, anyway.  I'm open to 
correction just as I tried to correct the parent, if needed.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: EAPI Changes

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 416 bytes --]

On Sun, 17 May 2009 20:40:41 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:
> (See EAPI-3, now preapproved, but conditional on feature
> implementation, with removal of some feature or other possible before
> final approval if not all PMs support it in a timely manner.)

EAPI 3's approval is based upon implementation in Portage, not
implementation in every other package manager.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] Re: EAPI Changes

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 3580 bytes --]

On Sun, 17 May 2009 21:03:46 +0200
Tiziano Müller <dev-zero@gentoo.org> wrote:

> Am Sonntag, den 17.05.2009, 11:11 -0600 schrieb Ryan Hill:
> > On Fri, 15 May 2009 23:31:25 +0200
> > Tiziano Müller <dev-zero@gentoo.org> wrote:
> > 
> > > Wrong. For example:
> > > - stuff like docompress may change the content being installed depending
> > > on the package manager
> > > - --disable-static (maybe in a later EAPI) changes content
> > > - slot-dep-operators change the rdepend of installed packages, so it
> > > changes how the package manager has to handle reverse packages on
> > > uninstall (in EAPI 3)
> > 
> > None of which are a problem when changing the EAPI from 0 to 1, which is the
> > situation here. The first two examples fall under the currently established
> > guideline of revbumping when content changes (and I emphasize guideline).  I
> > don't see how the third example is any different than adding or removing
> > dependencies, which also does not require a revbump.
>
> Which is mostly wrong as well since a change in dependency means that
> the currently installed stuff may break if a package (the new dependency
> for example) gets removed and since the package you changed does not
> reference it, it gets broken (for example if you had a magic dep before
> and add it now as an explicit dep).

I don't understand.  Removing a runtime dependency of a package will break it
regardless of whether or not it's referenced in the package's VDB.  We don't
prevent uninstalling dependencies, so how does having it referenced prevent
breakage?  The only case I can think of is depclean, but it already checks to
see if removing a package will break the linkage map of another installed
package.

> So, unless you're doing a pkgmove
> it's a dangerous thing since the PM can't reliably track reverse deps
> when doing uninstalls since it has to use the vdb entry for that,
> doesn't it?

Since when do we track reverse deps for uninstalls?

> >   So I'd argue that an
> > EAPI change does not require a revision bump in and of itself.
>
> EAPI may imply a decent implicit change to the ebuild and therefore
> needs a rev-bump as per the manual.

Exactly. :)

It's not the EAPI itself that requires the revbump, it's the changes the EAPI
makes.  That's all I'm saying.  And in the case of going from EAPI 0 to EAPI
1, the changes are not those that require a revbump.  If I were going from
EAPI 1 to 2, and I'm using the default src_compile, then yes, a revbump is in
order.

> > We may want to document a suggested waiting time before removing ebuilds
> > using older EAPI's.  For example, should we always keep an EAPI 0 ebuild in
> > stable as a fallback?  Or if the user tries to install or update a package
> > where all versions are masked by EAPI, should (does?) portage suggest updating
> > itself?
> It would maybe suggest to update to an unstable version of portage, not
> so good then?

If the user is installing a package that doesn't have a stable version with
an EAPI that their package manager supports, then it's no different than if
they are installing a package that doesn't have a stable version with their
KEYWORDS.  And when unmasking ~arch packages, you often have to unmask ~arch
dependencies.  Portage is just another of these dependencies.


-- 
gcc-porting,                                      by design, by neglect
treecleaner,                              for a fact or just for effect
wxwidgets @ gentoo     EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: EAPI Changes

[Arfrever Frehtes Taifersar Arahesis]

[-- Attachment #1: Type: text/plain, Size: 529 bytes --]

2009-05-17 22:51:50 Ryan Hill napisał(a):
> On Sun, 17 May 2009 21:03:46 +0200
> Tiziano Müller <dev-zero@gentoo.org> wrote:
> > So, unless you're doing a pkgmove
> > it's a dangerous thing since the PM can't reliably track reverse deps
> > when doing uninstalls since it has to use the vdb entry for that,
> > doesn't it?
> 
> Since when do we track reverse deps for uninstalls?

Portage supports `emerge --depclean ${package}` command which checks reverse dependencies.

-- 
Arfrever Frehtes Taifersar Arahesis

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] Re: EAPI Changes

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 1502 bytes --]

On Sun, 17 May 2009 20:40:41 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:

> Ryan Hill <dirtyepic@gentoo.org> posted
> 20090517111152.133c7280@halo.dirtyepic.sk.ca, excerpted below, on  Sun, 17
> May 2009 11:11:52 -0600:
> 
> >> Do we want to document the following? (do we have already?) - When is
> >> it allowed to use an EAPI in the tree (given as offset to the release
> >> of portage supporting that eapi) - When is it allowed to use an EAPI in
> >> the stable tree (given as offset of when a portage version supporting
> >> that EAPI got stable)
> > 
> > As soon as a version of portage supporting that EAPI is available.
> 
> That's a dangerous position to take.  See "experimental" EAPIs for 
> instance, sometimes temporarily supported by portage, but NOT for use in 
> the tree.
> 
> But I think you knew that and simply made some assumptions with the 
> statement that not all readers may have.

Yes, viewers at home, I'm speaking technically not politically.  Technically
you could add ebuilds for any EAPI the PM supports to the tree without
affecting users.  Politically, your fellow developers would stone you to
death, put you in a sack, and drop you to the bottom of the sea.  They might
even revoke your commit access too.


-- 
gcc-porting,                                      by design, by neglect
treecleaner,                              for a fact or just for effect
wxwidgets @ gentoo     EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] Re: EAPI Changes

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 910 bytes --]

On Sun, 17 May 2009 23:00:21 +0200
Arfrever Frehtes Taifersar Arahesis <arfrever.fta@gmail.com> wrote:

> 2009-05-17 22:51:50 Ryan Hill napisał(a):
> > On Sun, 17 May 2009 21:03:46 +0200
> > Tiziano Müller <dev-zero@gentoo.org> wrote:
> > > So, unless you're doing a pkgmove
> > > it's a dangerous thing since the PM can't reliably track reverse deps
> > > when doing uninstalls since it has to use the vdb entry for that,
> > > doesn't it?
> > 
> > Since when do we track reverse deps for uninstalls?
> 
> Portage supports `emerge --depclean ${package}` command which checks reverse dependencies.

But it also checks link level dependencies as well, doesn't it?


-- 
gcc-porting,                                      by design, by neglect
treecleaner,                              for a fact or just for effect
wxwidgets @ gentoo     EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] Re: EAPI Changes

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 2436 bytes --]

On Sun, 17 May 2009 15:19:17 -0600
Ryan Hill <dirtyepic@gentoo.org> wrote:

> On Sun, 17 May 2009 23:00:21 +0200
> Arfrever Frehtes Taifersar Arahesis <arfrever.fta@gmail.com> wrote:
> 
> > 2009-05-17 22:51:50 Ryan Hill napisał(a):
> > > On Sun, 17 May 2009 21:03:46 +0200
> > > Tiziano Müller <dev-zero@gentoo.org> wrote:
> > > > So, unless you're doing a pkgmove
> > > > it's a dangerous thing since the PM can't reliably track reverse deps
> > > > when doing uninstalls since it has to use the vdb entry for that,
> > > > doesn't it?
> > > 
> > > Since when do we track reverse deps for uninstalls?
> > 
> > Portage supports `emerge --depclean ${package}` command which checks reverse dependencies.
> 
> But it also checks link level dependencies as well, doesn't it?

halo ~ # grep chmlib /var/db/pkg/app-text/xchm-1.16/*
halo ~ # cat /var/db/pkg/app-text/xchm-1.16/NEEDED
/usr/bin/xchm libwx_gtk2u_aui-2.8.so.0,libwx_gtk2u_html-2.8.so.0,libwx_gtk2u_core-2.8.so.0,libwx_baseu_net-2.8.so.0,libwx_baseu-2.8.so.0,libchm.so.0,libstdc++.so.6,libgcc_s.so.1,libpthread.so.0,libc.so.6                                                                             
halo ~ # cat /var/db/pkg/app-text/xchm-1.16/NEEDED.ELF.2                                                                                    
X86_64;/usr/bin/xchm;;;libwx_gtk2u_aui-2.8.so.0,libwx_gtk2u_html-2.8.so.0,libwx_gtk2u_core-2.8.so.0,libwx_baseu_net-2.8.so.0,libwx_baseu-2.8.so.0,libchm.so.0,libstdc++.so.6,libgcc_s.so.1,libpthread.so.0,libc.so.6                                                                    
halo ~ # emerge --depclean -pv chmlib

Calculating dependencies... done!
>>> Checking for lib consumers...
>>> Assigning files to packages...
 * In order to avoid breakage of link level dependencies, one or more
 * packages will not be removed. This can be solved by rebuilding the
 * packages that pulled them in.
 *
 *   dev-libs/chmlib-0.39-r1 pulled in by:
 *     app-text/xchm-1.16
 *
>>> Adding lib providers to graph...
 -
Calculating dependencies... done!
  dev-libs/chmlib-0.39-r1 pulled in by:
    app-text/xchm-1.16

>>> No packages selected for removal by depclean




-- 
gcc-porting,                                      by design, by neglect
treecleaner,                              for a fact or just for effect
wxwidgets @ gentoo     EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]