Re: [gentoo-dev] EAPI-3 draft: slot operator support
Am Donnerstag, den 09.04.2009, 23:36 +0530 schrieb Nirbheek Chauhan: > On Thu, Apr 9, 2009 at 10:15 PM, Tiziano Müller wrote: > > roughly 90% packages depending on one of: > > > > sys-libs/db > > Why the hell does this have so many slots in-tree? I am unaware of the > reasons for it. Horribly changed API every release? How does every > other distro handle sys-libs/db ? Doesn't matter in this context since somebody just wanted examples. > > > dev-libs/boost > > Has one unmasked slot in-tree Oh, you got me. Nevertheless, will be 4 by the end of the week. > > > dev-lang/python > > > > So, wait, you want to depend on specific slots of python and keep them > around, and manage all their related bugs? Isn't that exactly the > opposite of what python upstream suggests, and *ALL* distros do? See dleverton's reply. > > > Besides: We wouldn't need the need_python_rebuild anymore, users could > > safely uninstall old sys-libs/db versions, old dev-libs/boost versions > > @preserved-libs. More generic, a low-level catch-all for library > breakages, and more convenient for users (rebuild as and when > possible, not *right now* lest everything break). > > > and the list of packages to reinstall in python-updater boils down to > > what "paludis -u dev-lang/python:2.4" spits out as reverse-dependencies > > (or the corresponding portage command). > > You mean emerge -C dev-lang/python:2.4 ? That'll say "bai bai python". > In any case, what is wrong with python_need_rebuild ? > > Slot operators need changes to the ebuilds, so does python_need_rebuild. > Slot operators need an EAPI bump for the ebuild, python_need_rebuild doesn't. > > So, isn't python_need_rebuild superior.. ? > No. Python rebuild makes explicit use of how vdb works. Which is not specified by eapi and therefore not guaranteed to work. But since you checked how things work before you start writing you already know that, don't you? signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] EAPI-3 draft: slot operator support
On Thursday 09 April 2009 19:06:16 Nirbheek Chauhan wrote: > > dev-lang/python > > So, wait, you want to depend on specific slots of python and keep them > around, and manage all their related bugs? Isn't that exactly the > opposite of what python upstream suggests, and *ALL* distros do? If you install a Python library for Python x.y, even if the library itself can support other versions, then the installed package depends on Python x.y, period. Using := is simply acknowledging that fact. It doesn't mean you have to keep x.y around for all time, but it does mean that the package manager knows what needs to be reinstalled before x.y can safely be removed. > @preserved-libs. More generic, a low-level catch-all for library > breakages, and more convenient for users (rebuild as and when > possible, not *right now* lest everything break). More generic? @preserved-libs knows about Python now? And the whole point of slotting is that you can keep old versions installed, so you don't need to rebuild dependent packages "right now".
Re: [gentoo-dev] EAPI-3 draft: slot operator support
On Thu, Apr 9, 2009 at 10:15 PM, Tiziano Müller wrote: > roughly 90% packages depending on one of: > > sys-libs/db Why the hell does this have so many slots in-tree? I am unaware of the reasons for it. Horribly changed API every release? How does every other distro handle sys-libs/db ? > dev-libs/boost Has one unmasked slot in-tree > dev-lang/python > So, wait, you want to depend on specific slots of python and keep them around, and manage all their related bugs? Isn't that exactly the opposite of what python upstream suggests, and *ALL* distros do? > Besides: We wouldn't need the need_python_rebuild anymore, users could > safely uninstall old sys-libs/db versions, old dev-libs/boost versions @preserved-libs. More generic, a low-level catch-all for library breakages, and more convenient for users (rebuild as and when possible, not *right now* lest everything break). > and the list of packages to reinstall in python-updater boils down to > what "paludis -u dev-lang/python:2.4" spits out as reverse-dependencies > (or the corresponding portage command). You mean emerge -C dev-lang/python:2.4 ? That'll say "bai bai python". In any case, what is wrong with python_need_rebuild ? Slot operators need changes to the ebuilds, so does python_need_rebuild. Slot operators need an EAPI bump for the ebuild, python_need_rebuild doesn't. So, isn't python_need_rebuild superior.. ? -- ~Nirbheek Chauhan
Re: [gentoo-dev] EAPI-3 draft: slot operator support
Am Donnerstag, den 09.04.2009, 12:03 +0200 schrieb Rémi Cardona: > Mart Raudsepp a écrit : > > Hello, > > > > > > This thread is for any discussion about the slot operator support item > > in EAPI-3 draft. > > Could anyone actually give a good reason for slot operators? What > packages would have a _clear_ benefit from using them? I'm asking for an > actual list of packages, not just some package that may exist in a > parallel universe. roughly 90% packages depending on one of: sys-libs/db dev-libs/boost dev-lang/python Sooo, something around 500 packages. Besides: We wouldn't need the need_python_rebuild anymore, users could safely uninstall old sys-libs/db versions, old dev-libs/boost versions and the list of packages to reinstall in python-updater boils down to what "paludis -u dev-lang/python:2.4" spits out as reverse-dependencies (or the corresponding portage command). signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] EAPI-3 draft: slot operator support
On Thu, 09 Apr 2009 05:25:33 +0300 Mart Raudsepp wrote: > Are we sure := and :* is the syntax that makes sense once we try to > cover some of the above with new syntax? := and :* covers the cases that can be covered with existing dependency ranges. If you want to cover things that need horrible || hacks with the current dependency format, you also need either to add ||= and ||* dependencies (which run against the definition of ||) or start supporting [>=2&<3] ranged dependencies. := and :* are appropriate. Your objections to them are based upon limitations with the current dependency format, and have nothing to do with := and :* themselves. They're not real limitations, either, since as Tiziano points out, in the real world there's a neat correspondence between version ranges and slots, and if there aren't you can't deal with them anyway. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI-3 draft: slot operator support
On Thu, 9 Apr 2009 17:06:47 +0530 Nirbheek Chauhan wrote: > So you're looking for ABI deps? @preserved-libs is the answer (C-sharp > support for that?). Suggested rebuilds upon upgrade? Separate issue, > separate solution (pkg_pretend maybe?) @preserved-libs is a horrible hack that is used in place of ABI deps. It requires a seperate implementation for each language/subset of packages and does not take into account "silent" ABI breakage. *DO*NOT*WANT* In other words. :-)
Re: [gentoo-dev] EAPI-3 draft: slot operator support
On Thu, Apr 9, 2009 at 4:56 PM, Peter Alfredsen wrote: > As I said, I would be using slot-deps as ABI-deps. I would find actual > ABI deps to be vastly more useful since I wouldn't have to keep track > of earlier slots to block. > > Imagine a world with no revdep-rebuild? > So you're looking for ABI deps? @preserved-libs is the answer (C-sharp support for that?). Suggested rebuilds upon upgrade? Separate issue, separate solution (pkg_pretend maybe?) -- ~Nirbheek Chauhan
Re: [gentoo-dev] EAPI-3 draft: slot operator support
On Thu, 9 Apr 2009 16:29:53 +0530 Nirbheek Chauhan wrote: > I think the current way is the most easily-supportable way for us. > Complex interdependencies b/w packages and slots => O(n^k) times bugs, > where k = no. of slots for a library. > > If we don't get all those bugs, it means people are running the latest > package and latest slot. So slot operators would be m00t in that case. I wouldn't be using slotdeps as actual slotdeps, more like ABI deps. Each slot would soft-block all other slots, so upgrades would be handled normally by portage. Only, all other packages could use slotdeps to be rebuilt when a new version of gtk-sharp is released. It would probably take a bit of eclass fudgery, but it could be made to work. Also, it would allow people to mix ~arch and arch for -sharp stuff. Which would be good. As I said, I would be using slot-deps as ABI-deps. I would find actual ABI deps to be vastly more useful since I wouldn't have to keep track of earlier slots to block. Imagine a world with no revdep-rebuild? /loki_val
Re: [gentoo-dev] EAPI-3 draft: slot operator support
On N, 2009-04-09 at 11:30 +0200, Tiziano Müller wrote:
> Am Donnerstag, den 09.04.2009, 05:25 +0300 schrieb Mart Raudsepp:
> > Hello,
> >
> >
> > This thread is for any discussion about the slot operator support item
> > in EAPI-3 draft.
> >
> > The premise is good what := and :* allow for, but I'm concerned about
> > the syntax possibly ending up being suboptimal in relation to the syntax
> > we come up in the future for covering the cases not covered now.
> >
> >
> > Such cases are for example:
> >
> > * A library package has slots 2.4, 2.6 and 2.8. An application works
> > with either 2.6 or 2.8, but needs a recompile for changed ABI. It does
> > not work with 2.4 - it has API missing that it needs.
> DEPEND=RDEPEND=">=cat/lib-2.6:="
This is an abuse of the version number. There is no actual guarantee
that SLOT 2.6 revisions carry a 2.6* version number, etc.
> > * Same case as previous, but additionally the library has a version with
> > slot 3.0 - it is a complete redesign and applications working with 2.8
> > have no chance of working. So need to express a list of acceptable SLOTs
> > or a minimum and maximum (but slots aren't really guaranteed to be
> > numeric and versionable).
> slot operators won't help here, so it remains:
> RDEPEND="|| ( cat/lib:2.6 cat/lib:2.8 )"
The package additionally needs to know which one the package manager
picked for it, to instruct the build system to actually use that
version.
Without this the whole := deal is pretty useless for many cases.
> with ranged dependencies:
> RDEPEND="cat/lib[>=2.6&<3]:="
Version/slot mixing abuse
> or slot ranges:
> RDEPEND="cat/lib:[2.6|2.8]="
> or
> RDEPEND="cat/lib:=[2.6|2.8]"
> (depends on how we want to define the syntax)
I guess that would go along with the := proposed now and therefore be an
evolution and not a problem to do := now. At least for this case.
> > * Same case as previous (either of them), but if using SLOT 2.6, it
> > needs to be at least >=libr/ary-2.6.5:2.6 and if SLOT 2.8 at least
> > >=libr/ary-2.8.3:2.8. A re-compile if switching provider may or may not
> > be necessary (considering both cases separately)
> slot operators won't help here, so it remains:
> RDEPEND="|| ( >=cat/lib-2.8.3:2.8 >=cat/lib-2.6.5:2.6 )"
That doesn't work for the same reason cat/lib or || ( cat/lib:2.6
cat/lib:2.8 ) doesn't.
> again with ranged dependencies (somebody please check this):
> RDEPEND="cat/lib[<3.0&(>=2.8.3|>=2.6.5)]:="
> or
> RDEPEND="cat/lib[<3.0&(>=2.8.3|>=2.6.5)]:*"
>
> or maybe combined with slot ranges:
> RDEPEND="cat/lib[>=2.8.3|>=2.6.5]:=[2.8|2.6]
There is no relation between 2.8.3 and slot 2.8 here really.
We do not declare anywhere how SLOT naming related to version numbers
it's used in. So none of those examples work for me.
> please note: the ebuild maintainer has to make sure that the package has
> to use the best-matching version, otherwise even the slot specifiers are
> worthless.
The package manager needs to tell the ebuild which version it went with,
or this doesn't work right. If you assume best matching version always,
then all this slot operator deal becomes superfluous. Maintainers should
then simply always depend on just the latest version and there is
minimal benefits to slot operators and the complexity in the readability
might not be worth it.
> Real-world example for that:
> DEPEND="sys-libs/db:="
> RDEPEND="${RDEPEND}"
>
> By the time of installation you have sys-libs/db:{4.6,4.7} installed,
> then your app has to use sys-libs/db:4.7.
> (best_version should provide that information as far as I know).
>
> >
> > * A library provides slots 1.2, 1.4 and 1.6. An application can work
> > with all of them, but needs a recompile if upgrading from being linked
> > against 1.2 to newer. 1.4 and 1.6 are runtime interchangeable. Very rare
> > possibility of this though, involving dlopen and more. Probably
> > acceptable to declare rebuild need for all changes.
> Yes.
>
> > Are we sure := and :* is the syntax that makes sense once we try to
> > cover some of the above with new syntax?
> Yes. It's quiet extendable (as seen above).
>
> >
> > Perhaps some forward thinking is sensible here to not end up with having
> > to deprecate the := and :* syntax soon after its introduction.
> Done.
I see no need for :* based on the examples provided and can't think of
any real world cases for it either right now.
There is that theoretical case when some package does dynamic usage of
the library through dlopen and handles the ABI differences, but even
then there is no guarantee (and it is quite unlikely) that it can handle
a future ABI SLOT of the library, and so using :* is unsafe, and :=[list
of known to work ABI SLOTs] should be used instead.
--
Mart Raudsepp
Gentoo Developer
Mail: l...@gentoo.org
Weblog: http://planet.gentoo.org/developers/leio
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] EAPI-3 draft: slot operator support
On Thu, Apr 9, 2009 at 4:09 PM, Peter Alfredsen wrote: > All package depending on dev-dotnet/gtk-sharp. Although these won't be > parallel-installable slots, it will really easy the transition between > versions and allow us to ease the currently quite strict > interdependencies between the various packages that make up the > gtk-sharp, gnome-sharp and gnome-desktop-sharp tarballs, where all > versions of all packages are bound to a single gtk-sharp major version > (2.12 at the moment). Currently we handle bumps in api by bumping every > package in this trifecta from hell. That way, users only have to > rebuild their apps, portage will take care of rebuilding the -sharp > libs. > I think the current way is the most easily-supportable way for us. Complex interdependencies b/w packages and slots => O(n^k) times bugs, where k = no. of slots for a library. If we don't get all those bugs, it means people are running the latest package and latest slot. So slot operators would be m00t in that case. -- ~Nirbheek Chauhan
Re: [gentoo-dev] EAPI-3 draft: slot operator support
On Thu, 09 Apr 2009 12:03:03 +0200 Rémi Cardona wrote: > Could anyone actually give a good reason for slot operators? What > packages would have a _clear_ benefit from using them? I'm asking for > an actual list of packages, not just some package that may exist in a > parallel universe. All package depending on dev-dotnet/gtk-sharp. Although these won't be parallel-installable slots, it will really easy the transition between versions and allow us to ease the currently quite strict interdependencies between the various packages that make up the gtk-sharp, gnome-sharp and gnome-desktop-sharp tarballs, where all versions of all packages are bound to a single gtk-sharp major version (2.12 at the moment). Currently we handle bumps in api by bumping every package in this trifecta from hell. That way, users only have to rebuild their apps, portage will take care of rebuilding the -sharp libs.
Re: [gentoo-dev] EAPI-3 draft: slot operator support
Mart Raudsepp a écrit : Hello, This thread is for any discussion about the slot operator support item in EAPI-3 draft. Could anyone actually give a good reason for slot operators? What packages would have a _clear_ benefit from using them? I'm asking for an actual list of packages, not just some package that may exist in a parallel universe. To me it just looks like it's overly complicated and it makes my eyes bleed. Rémi
Re: [gentoo-dev] EAPI-3 draft: slot operator support
Am Donnerstag, den 09.04.2009, 05:25 +0300 schrieb Mart Raudsepp:
> Hello,
>
>
> This thread is for any discussion about the slot operator support item
> in EAPI-3 draft.
>
> The premise is good what := and :* allow for, but I'm concerned about
> the syntax possibly ending up being suboptimal in relation to the syntax
> we come up in the future for covering the cases not covered now.
>
>
> Such cases are for example:
>
> * A library package has slots 2.4, 2.6 and 2.8. An application works
> with either 2.6 or 2.8, but needs a recompile for changed ABI. It does
> not work with 2.4 - it has API missing that it needs.
DEPEND=RDEPEND=">=cat/lib-2.6:="
> * Same case as previous, but additionally the library has a version with
> slot 3.0 - it is a complete redesign and applications working with 2.8
> have no chance of working. So need to express a list of acceptable SLOTs
> or a minimum and maximum (but slots aren't really guaranteed to be
> numeric and versionable).
slot operators won't help here, so it remains:
RDEPEND="|| ( cat/lib:2.6 cat/lib:2.8 )"
with ranged dependencies:
RDEPEND="cat/lib[>=2.6&<3]:="
or slot ranges:
RDEPEND="cat/lib:[2.6|2.8]="
or
RDEPEND="cat/lib:=[2.6|2.8]"
(depends on how we want to define the syntax)
> * Same case as previous (either of them), but if using SLOT 2.6, it
> needs to be at least >=libr/ary-2.6.5:2.6 and if SLOT 2.8 at least
> >=libr/ary-2.8.3:2.8. A re-compile if switching provider may or may not
> be necessary (considering both cases separately)
slot operators won't help here, so it remains:
RDEPEND="|| ( >=cat/lib-2.8.3:2.8 >=cat/lib-2.6.5:2.6 )"
again with ranged dependencies (somebody please check this):
RDEPEND="cat/lib[<3.0&(>=2.8.3|>=2.6.5)]:="
or
RDEPEND="cat/lib[<3.0&(>=2.8.3|>=2.6.5)]:*"
or maybe combined with slot ranges:
RDEPEND="cat/lib[>=2.8.3|>=2.6.5]:=[2.8|2.6]
please note: the ebuild maintainer has to make sure that the package has
to use the best-matching version, otherwise even the slot specifiers are
worthless.
Real-world example for that:
DEPEND="sys-libs/db:="
RDEPEND="${RDEPEND}"
By the time of installation you have sys-libs/db:{4.6,4.7} installed,
then your app has to use sys-libs/db:4.7.
(best_version should provide that information as far as I know).
>
> * A library provides slots 1.2, 1.4 and 1.6. An application can work
> with all of them, but needs a recompile if upgrading from being linked
> against 1.2 to newer. 1.4 and 1.6 are runtime interchangeable. Very rare
> possibility of this though, involving dlopen and more. Probably
> acceptable to declare rebuild need for all changes.
Yes.
> Are we sure := and :* is the syntax that makes sense once we try to
> cover some of the above with new syntax?
Yes. It's quiet extendable (as seen above).
>
> Perhaps some forward thinking is sensible here to not end up with having
> to deprecate the := and :* syntax soon after its introduction.
Done.
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
[gentoo-dev] EAPI-3 draft: slot operator support
Hello, This thread is for any discussion about the slot operator support item in EAPI-3 draft. The premise is good what := and :* allow for, but I'm concerned about the syntax possibly ending up being suboptimal in relation to the syntax we come up in the future for covering the cases not covered now. Such cases are for example: * A library package has slots 2.4, 2.6 and 2.8. An application works with either 2.6 or 2.8, but needs a recompile for changed ABI. It does not work with 2.4 - it has API missing that it needs. * Same case as previous, but additionally the library has a version with slot 3.0 - it is a complete redesign and applications working with 2.8 have no chance of working. So need to express a list of acceptable SLOTs or a minimum and maximum (but slots aren't really guaranteed to be numeric and versionable). * Same case as previous (either of them), but if using SLOT 2.6, it needs to be at least >=libr/ary-2.6.5:2.6 and if SLOT 2.8 at least >=libr/ary-2.8.3:2.8. A re-compile if switching provider may or may not be necessary (considering both cases separately) * A library provides slots 1.2, 1.4 and 1.6. An application can work with all of them, but needs a recompile if upgrading from being linked against 1.2 to newer. 1.4 and 1.6 are runtime interchangeable. Very rare possibility of this though, involving dlopen and more. Probably acceptable to declare rebuild need for all changes. Are we sure := and :* is the syntax that makes sense once we try to cover some of the above with new syntax? Perhaps some forward thinking is sensible here to not end up with having to deprecate the := and :* syntax soon after its introduction. -- Mart Raudsepp Gentoo Developer Mail: l...@gentoo.org Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
