[gentoo-dev] Re: EAPI Changes
On Sun, 17 May 2009 15:19:17 -0600
Ryan Hill wrote:
> On Sun, 17 May 2009 23:00:21 +0200
> Arfrever Frehtes Taifersar Arahesis wrote:
>
> > 2009-05-17 22:51:50 Ryan Hill napisał(a):
> > > On Sun, 17 May 2009 21:03:46 +0200
> > > Tiziano Müller 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
signature.asc
Description: PGP signature
[gentoo-dev] Re: EAPI Changes
On Sun, 17 May 2009 23:00:21 +0200
Arfrever Frehtes Taifersar Arahesis wrote:
> 2009-05-17 22:51:50 Ryan Hill napisał(a):
> > On Sun, 17 May 2009 21:03:46 +0200
> > Tiziano Müller 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
signature.asc
Description: PGP signature
[gentoo-dev] Re: EAPI Changes
On Sun, 17 May 2009 20:40:41 + (UTC) Duncan <1i5t5.dun...@cox.net> wrote: > Ryan Hill posted > 2009051752.133c7...@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 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: EAPI Changes
2009-05-17 22:51:50 Ryan Hill napisał(a):
> On Sun, 17 May 2009 21:03:46 +0200
> Tiziano Müller 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
signature.asc
Description: This is a digitally signed message part.
[gentoo-dev] Re: EAPI Changes
On Sun, 17 May 2009 21:03:46 +0200 Tiziano Müller 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 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 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: EAPI Changes
On Sun, 17 May 2009 20:40:41 + (UTC) Duncan <1i5t5.dun...@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 signature.asc Description: PGP signature
[gentoo-dev] Re: EAPI Changes
Ryan Hill posted 2009051752.133c7...@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
Am Sonntag, den 17.05.2009, 11:11 -0600 schrieb Ryan Hill: > On Fri, 15 May 2009 23:31:25 +0200 > Tiziano Müller 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-z...@gentoo.org GnuPG FP : F327 283A E769 2E36 18D5 4DE2 1B05 6A63 AE9C 1E30 signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
[gentoo-dev] Re: EAPI Changes
On Fri, 15 May 2009 23:31:25 +0200 Tiziano Müller 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 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: EAPI Changes
Duncan wrote: > Petteri Räty posted 4a0dd0ed.1070...@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 signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: EAPI Changes
Petteri Räty posted 4a0dd0ed.1070...@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
