Re: [gentoo-dev] About forcing rebuilds of other packages issue
Zac Medico wrote: I'd suggest a special ebuild phase to check for ABI changes, like the pre_pkg_preinst_abi_check phase suggested here: https://bugs.gentoo.org/show_bug.cgi?id=192319#c20 I guess, that phase would detect ABI change and package manager would know how to handle it by itself? Yeah, it would be like a warning system, And once we bump SLOT/ABI_SLOT, package manager would know about how to handle that situation and rebuild needed stuff? Is it unrealistic to assume that upstream ABI providers will mark their ABIs by using sonames correctly? Maybe that is at least the common case, then ABI_SLOT could be set automatically. Maybe I'm too far ahead, and baby steps are better. //Peter
Re: [gentoo-dev] About forcing rebuilds of other packages issue
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/07/12 07:29 AM, Peter Stuge wrote: Zac Medico wrote: I'd suggest a special ebuild phase to check for ABI changes, like the pre_pkg_preinst_abi_check phase suggested here: https://bugs.gentoo.org/show_bug.cgi?id=192319#c20 I guess, that phase would detect ABI change and package manager would know how to handle it by itself? Yeah, it would be like a warning system, And once we bump SLOT/ABI_SLOT, package manager would know about how to handle that situation and rebuild needed stuff? Is it unrealistic to assume that upstream ABI providers will mark their ABIs by using sonames correctly? Maybe that is at least the common case, then ABI_SLOT could be set automatically. Maybe I'm too far ahead, and baby steps are better. Although we have a lot of this information available (which is why/how @preserved-libs works, for instance), there is no way for portage to know *prior to emerging the update* if abi has changed. This is why it needs to be specified in the ebuild somehow (and sub-slots via 4-slot-abi seem very capable of handling this) That said, while experimenting with 4-slot-abi porting on my overlay, usually I am just specifying the major (or sometimes major.minor) version parts of the sonames, since that seems to make the most sense usually. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAk/4Q2IACgkQ2ugaI38ACPBzagD/blTq3Dq1K9Yrv2PdxSirxwu7 POUSNlLr59x8jKaE2oYBAIS+mATPRj3vn1W/uB37ipLmbg76gbcr7LTqh6Mb7Unv =VKuj -END PGP SIGNATURE-
Re: [gentoo-dev] About forcing rebuilds of other packages issue
Ian Stakenvicius wrote: Is it unrealistic to assume that upstream ABI providers will mark their ABIs by using sonames correctly? Maybe that is at least the common case, then ABI_SLOT could be set automatically. Although we have a lot of this information available (which is why/how @preserved-libs works, for instance), there is no way for portage to know *prior to emerging the update* if abi has changed. Knowing that a library changes ABI before building is nice, but not relying on a human to encode this is nicer still. After compile, before install, there is an opportunity to show the effects of installing the package. I'm only talking about the context of the developer who is adding the new ebuild. So ABI_SLOT (or / SLOT) would be set automatically just once, in the process of committing the ebuild. No need to repeat the binary analysis - except if one source package has different ABI for different ARCHes. Fun! //Peter
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On 07/07/2012 11:54 AM, Peter Stuge wrote: Ian Stakenvicius wrote: Is it unrealistic to assume that upstream ABI providers will mark their ABIs by using sonames correctly? Maybe that is at least the common case, then ABI_SLOT could be set automatically. Although we have a lot of this information available (which is why/how @preserved-libs works, for instance), there is no way for portage to know *prior to emerging the update* if abi has changed. Knowing that a library changes ABI before building is nice, but not relying on a human to encode this is nicer still. After compile, before install, there is an opportunity to show the effects of installing the package. I'm only talking about the context of the developer who is adding the new ebuild. So ABI_SLOT (or / SLOT) would be set automatically just once, in the process of committing the ebuild. Well, if you're talking about having portage automatically edit the ebuild, I don't think we want to do that. If developers use portage-2.2_alpha with preserve-libs, then they'll know automatically when there's an SONAME change that triggers preserve-libs. Part of the beauty of the approach used in EAPI 4-slot-abi is that that it can be used to trigger rebuilds in cases that don't even involve SONAME dependencies (consider a pure perl module that only needs to be rebuilt in order to install its interpreted *.pm files in a different directory for a new version of perl). No need to repeat the binary analysis - except if one source package has different ABI for different ARCHes. Fun! It might be nice to add some binary analysis things beyond preserve-libs in the future. However, EAPI 4-slot-abi should work quite well even without that. It just automates rebuilds [1] that the user was previously required to handle manually, when prompted by elog messages, or by running tools like revdep-rebuild and perl-cleaner. It's being tested in the axs overlay [2], and it seems to be working pretty well. [1] http://blogs.gentoo.org/zmedico/2012/06/23/automatic-rebuilds-with-experimental-eapi-4-slot-abi/ [2] http://git.overlays.gentoo.org/gitweb/?p=dev/axs.git;a=summary -- Thanks, Zac
Re: [gentoo-dev] About forcing rebuilds of other packages issue
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 25/06/12 01:58 PM, Zac Medico wrote: On 06/25/2012 06:03 AM, Ian Stakenvicius wrote: On 23/06/12 08:42 PM, Zac Medico wrote: On 06/10/2012 11:18 AM, Zac Medico wrote: On 06/10/2012 05:25 AM, Ciaran McCreesh wrote: On Sat, 09 Jun 2012 13:55:53 -0700 Zac Medico zmed...@gentoo.org wrote: A dependency atom will have optional SLOT and ABI_SLOT parts. Using the dbus-glib depedency on glib:2 as an example [1], the dbus-glib dependency will be expressed with an atom such as dev-libs/glib:2:= and the package manager will translate that atom to dev-libs/glib:2:=2.32 at build time. So, ':' is always used to distinguish SLOT deps, and ':=' is always used to distinguish ABI_SLOT deps. Is that syntax good? Here's a nicer syntax: no ABI_SLOT variable, and SLOT=2/2.32. Then you can do explicit :2/2.32 dependencies if you like, or :2 (which would match SLOT=2 or SLOT=2/anything), or :2= (which gets rewritten to :2/2.32=) or :2*. If an ebuild does SLOT=2, it's treated as 2/2. Yes, I prefer your syntax. In portage-2.1.11.1 and 2.2.0_alpha112 I’ve added support for EAPI “4-slot-abi”: http://blogs.gentoo.org/zmedico/2012/06/23/automatic-rebuilds-with-experimental-eapi-4-slot-abi/ Does anyone have a fork of the tree that's being converted to test this new functionality? If so I'd like to sign up. That would be nice to have, but I haven't heard of anyone doing it yet. Well, I am now. If anyone wants to test, i'm going to make an attempt to keep the following overlay in sync with the main tree within a 24-hour delay (excluding weekends). git://git.overlays.gentoo.org/dev/axs.git FYI, all the work subslotting the perl stuff doesn't work yet, so it's probably best to wait a few days before trying it out. Sorry, no means of bug reporting on any of this yet (ie, don't file on b.g.o about it), but i'm in #-dev on freenode most weekdays. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAk/rYTgACgkQ2ugaI38ACPAOvwD/WBqDNCnCJLZw+2302SJOZzO4 cDYOcr3nNk5JeMVz1YAA/jrllZuqcl2skF0WBf4ku8Jb8dsTucddqB3SarxSBB25 =Efzw -END PGP SIGNATURE-
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On 06/25/2012 06:03 AM, Ian Stakenvicius wrote: On 23/06/12 08:42 PM, Zac Medico wrote: On 06/10/2012 11:18 AM, Zac Medico wrote: On 06/10/2012 05:25 AM, Ciaran McCreesh wrote: On Sat, 09 Jun 2012 13:55:53 -0700 Zac Medico zmed...@gentoo.org wrote: A dependency atom will have optional SLOT and ABI_SLOT parts. Using the dbus-glib depedency on glib:2 as an example [1], the dbus-glib dependency will be expressed with an atom such as dev-libs/glib:2:= and the package manager will translate that atom to dev-libs/glib:2:=2.32 at build time. So, ':' is always used to distinguish SLOT deps, and ':=' is always used to distinguish ABI_SLOT deps. Is that syntax good? Here's a nicer syntax: no ABI_SLOT variable, and SLOT=2/2.32. Then you can do explicit :2/2.32 dependencies if you like, or :2 (which would match SLOT=2 or SLOT=2/anything), or :2= (which gets rewritten to :2/2.32=) or :2*. If an ebuild does SLOT=2, it's treated as 2/2. Yes, I prefer your syntax. In portage-2.1.11.1 and 2.2.0_alpha112 I’ve added support for EAPI “4-slot-abi”: http://blogs.gentoo.org/zmedico/2012/06/23/automatic-rebuilds-with-experimental-eapi-4-slot-abi/ Does anyone have a fork of the tree that's being converted to test this new functionality? If so I'd like to sign up. That would be nice to have, but I haven't heard of anyone doing it yet. -- Thanks, Zac
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On 06/10/2012 11:18 AM, Zac Medico wrote: On 06/10/2012 05:25 AM, Ciaran McCreesh wrote: On Sat, 09 Jun 2012 13:55:53 -0700 Zac Medico zmed...@gentoo.org wrote: A dependency atom will have optional SLOT and ABI_SLOT parts. Using the dbus-glib depedency on glib:2 as an example [1], the dbus-glib dependency will be expressed with an atom such as dev-libs/glib:2:= and the package manager will translate that atom to dev-libs/glib:2:=2.32 at build time. So, ':' is always used to distinguish SLOT deps, and ':=' is always used to distinguish ABI_SLOT deps. Is that syntax good? Here's a nicer syntax: no ABI_SLOT variable, and SLOT=2/2.32. Then you can do explicit :2/2.32 dependencies if you like, or :2 (which would match SLOT=2 or SLOT=2/anything), or :2= (which gets rewritten to :2/2.32=) or :2*. If an ebuild does SLOT=2, it's treated as 2/2. Yes, I prefer your syntax. In portage-2.1.11.1 and 2.2.0_alpha112 I’ve added support for EAPI “4-slot-abi”: http://blogs.gentoo.org/zmedico/2012/06/23/automatic-rebuilds-with-experimental-eapi-4-slot-abi/ -- Thanks, Zac
Re: [gentoo-dev] About forcing rebuilds of other packages issue
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 10/06/12 06:49 PM, Brian Harring wrote: On Sun, Jun 10, 2012 at 01:25:55PM +0100, Ciaran McCreesh wrote: On Sat, 09 Jun 2012 13:55:53 -0700 Zac Medico zmed...@gentoo.org wrote: A dependency atom will have optional SLOT and ABI_SLOT parts. Using the dbus-glib depedency on glib:2 as an example [1], the dbus-glib dependency will be expressed with an atom such as dev-libs/glib:2:= and the package manager will translate that atom to dev-libs/glib:2:=2.32 at build time. So, ':' is always used to distinguish SLOT deps, and ':=' is always used to distinguish ABI_SLOT deps. Is that syntax good? Here's a nicer syntax: no ABI_SLOT variable, and SLOT=2/2.32. Hate the slash; just looks ugly to me (so starts the bikeshed). Sans that naggle, notions fine however; not sure I'm a fan of people being able to specify the exact ABI they need from an ebuild while it's in source form, but may be of use for emul-* packages. ~harring It's power will come from detection of the different SLOT= assignment between ebuilds of a particular library package. I don't forsee that there is going to be very much usage of the '/[ABI]' part in *DEPEND. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iF4EAREIAAYFAk/XX7QACgkQ2ugaI38ACPDo6QD/XqsVP0UWmLrzxwFF1f2W6UsM aA3wM6aqYX+wc+uHGTAA/jk8jz6kCs5rEudSWWXYndg6LEKp1Rj+YC/C7tLlk9uW =tDdT -END PGP SIGNATURE-
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On Sat, 09 Jun 2012 13:55:53 -0700 Zac Medico zmed...@gentoo.org wrote: A dependency atom will have optional SLOT and ABI_SLOT parts. Using the dbus-glib depedency on glib:2 as an example [1], the dbus-glib dependency will be expressed with an atom such as dev-libs/glib:2:= and the package manager will translate that atom to dev-libs/glib:2:=2.32 at build time. So, ':' is always used to distinguish SLOT deps, and ':=' is always used to distinguish ABI_SLOT deps. Is that syntax good? Here's a nicer syntax: no ABI_SLOT variable, and SLOT=2/2.32. Then you can do explicit :2/2.32 dependencies if you like, or :2 (which would match SLOT=2 or SLOT=2/anything), or :2= (which gets rewritten to :2/2.32=) or :2*. If an ebuild does SLOT=2, it's treated as 2/2. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On Sun, Jun 10, 2012 at 2:25 PM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Sat, 09 Jun 2012 13:55:53 -0700 Zac Medico zmed...@gentoo.org wrote: A dependency atom will have optional SLOT and ABI_SLOT parts. Using the dbus-glib depedency on glib:2 as an example [1], the dbus-glib dependency will be expressed with an atom such as dev-libs/glib:2:= and the package manager will translate that atom to dev-libs/glib:2:=2.32 at build time. So, ':' is always used to distinguish SLOT deps, and ':=' is always used to distinguish ABI_SLOT deps. Is that syntax good? Here's a nicer syntax: no ABI_SLOT variable, and SLOT=2/2.32. Then you can do explicit :2/2.32 dependencies if you like, or :2 (which would match SLOT=2 or SLOT=2/anything), or :2= (which gets rewritten to :2/2.32=) or :2*. If an ebuild does SLOT=2, it's treated as 2/2. I was going to propose a very similar syntax, i.e. using a slash to separate the regular SLOT part from the new ABI part, so +1 for Ciaran's proposal. Thanks, Pesa
Re: [gentoo-dev] About forcing rebuilds of other packages issue
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 10/06/12 08:45 AM, Davide Pesavento wrote: On Sun, Jun 10, 2012 at 2:25 PM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Sat, 09 Jun 2012 13:55:53 -0700 Zac Medico zmed...@gentoo.org wrote: A dependency atom will have optional SLOT and ABI_SLOT parts. Using the dbus-glib depedency on glib:2 as an example [1], the dbus-glib dependency will be expressed with an atom such as dev-libs/glib:2:= and the package manager will translate that atom to dev-libs/glib:2:=2.32 at build time. So, ':' is always used to distinguish SLOT deps, and ':=' is always used to distinguish ABI_SLOT deps. Is that syntax good? Here's a nicer syntax: no ABI_SLOT variable, and SLOT=2/2.32. Then you can do explicit :2/2.32 dependencies if you like, or :2 (which would match SLOT=2 or SLOT=2/anything), or :2= (which gets rewritten to :2/2.32=) or :2*. If an ebuild does SLOT=2, it's treated as 2/2. I was going to propose a very similar syntax, i.e. using a slash to separate the regular SLOT part from the new ABI part, so +1 for Ciaran's proposal. Thanks, Pesa This looks very promising -- then for libs where we only want to support one API, we could still use SLOT=0 via (ie for libpng) SLOT=0/1.5 +1 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iF4EAREIAAYFAk/Um/YACgkQ2ugaI38ACPDuDwD9F0mLVsh1rwUufL2HCB0Jjl2b KkNa5z9I4s6lDQmPdIoBAKlPBrtN4C87qFjeJRBkytJvRn8ZF82kSQ0R7ik3UPqc =EYRI -END PGP SIGNATURE-
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On 06/10/2012 05:25 AM, Ciaran McCreesh wrote: On Sat, 09 Jun 2012 13:55:53 -0700 Zac Medico zmed...@gentoo.org wrote: A dependency atom will have optional SLOT and ABI_SLOT parts. Using the dbus-glib depedency on glib:2 as an example [1], the dbus-glib dependency will be expressed with an atom such as dev-libs/glib:2:= and the package manager will translate that atom to dev-libs/glib:2:=2.32 at build time. So, ':' is always used to distinguish SLOT deps, and ':=' is always used to distinguish ABI_SLOT deps. Is that syntax good? Here's a nicer syntax: no ABI_SLOT variable, and SLOT=2/2.32. Then you can do explicit :2/2.32 dependencies if you like, or :2 (which would match SLOT=2 or SLOT=2/anything), or :2= (which gets rewritten to :2/2.32=) or :2*. If an ebuild does SLOT=2, it's treated as 2/2. Yes, I prefer your syntax. -- Thanks, Zac
Re: [gentoo-dev] About forcing rebuilds of other packages issue
El dom, 10-06-2012 a las 13:25 +0100, Ciaran McCreesh escribió: On Sat, 09 Jun 2012 13:55:53 -0700 Zac Medico zmed...@gentoo.org wrote: A dependency atom will have optional SLOT and ABI_SLOT parts. Using the dbus-glib depedency on glib:2 as an example [1], the dbus-glib dependency will be expressed with an atom such as dev-libs/glib:2:= and the package manager will translate that atom to dev-libs/glib:2:=2.32 at build time. So, ':' is always used to distinguish SLOT deps, and ':=' is always used to distinguish ABI_SLOT deps. Is that syntax good? Here's a nicer syntax: no ABI_SLOT variable, and SLOT=2/2.32. Then you can do explicit :2/2.32 dependencies if you like, or :2 (which would match SLOT=2 or SLOT=2/anything), or :2= (which gets rewritten to :2/2.32=) or :2*. If an ebuild does SLOT=2, it's treated as 2/2. Looks nice to me :) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On Sun, Jun 10, 2012 at 01:25:55PM +0100, Ciaran McCreesh wrote: On Sat, 09 Jun 2012 13:55:53 -0700 Zac Medico zmed...@gentoo.org wrote: A dependency atom will have optional SLOT and ABI_SLOT parts. Using the dbus-glib depedency on glib:2 as an example [1], the dbus-glib dependency will be expressed with an atom such as dev-libs/glib:2:= and the package manager will translate that atom to dev-libs/glib:2:=2.32 at build time. So, ':' is always used to distinguish SLOT deps, and ':=' is always used to distinguish ABI_SLOT deps. Is that syntax good? Here's a nicer syntax: no ABI_SLOT variable, and SLOT=2/2.32. Hate the slash; just looks ugly to me (so starts the bikeshed). Sans that naggle, notions fine however; not sure I'm a fan of people being able to specify the exact ABI they need from an ebuild while it's in source form, but may be of use for emul-* packages. ~harring
Re: [gentoo-dev] About forcing rebuilds of other packages issue
El vie, 08-06-2012 a las 12:31 -0700, Zac Medico escribió: On 06/08/2012 12:23 PM, Pacho Ramos wrote: El vie, 08-06-2012 a las 12:16 -0700, Zac Medico escribió: On 06/08/2012 01:38 AM, Pacho Ramos wrote: El jue, 07-06-2012 a las 12:33 -0700, Zac Medico escribió: On 06/07/2012 12:24 PM, Pacho Ramos wrote: El jue, 07-06-2012 a las 12:09 -0700, Zac Medico escribió: On 06/07/2012 12:00 PM, Pacho Ramos wrote: El jue, 07-06-2012 a las 19:44 +0100, Ciaran McCreesh escribió: On Thu, 07 Jun 2012 20:43:54 +0200 Pacho Ramos pa...@gentoo.org wrote: I would prefer, as a workaround, allow reverse deps to RDEPEND on glib:2.* instead. That way it would cover more cases when more than two slots are available Well, per: http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commitdiff;h=f9f7729c047300e1924ad768a49c660e12c2f906;hp=b7750e67b4772c1064543defb7df6a556f09807b looks like * usage for SLOTs would be allowed :), or I am misinterpreting it? It's not a wildcard. But it looks like a valid usage for cases like glib vs. dbus-glib/gobject-introspection I have exposed as example, and also allows us to keep SLOT over ABI_SLOT (at least for this case, not sure about others I could be missing now...) The :* operator doesn't trigger any rebuilds though. Quoting the PMS patch that you linked: * Indicates that any slot value is acceptable. In addition, for runtime dependencies, indicates that the package will not break if the matched package is uninstalled and replaced by a different matching package in a different slot. I mean, use it in conjunction with :=, one for rebuild and other to indicate any 2.x SLOT fits the normal RDEPEND (to not need to periodically update RDEPENDs or need to go back from :SLOT depends to old =category/package-version-* ways) Allowing that, we wouldn't need ABI_SLOT (at least to prevent this issue that arises with using only SLOTs for this) What you're talking about here is more similar to ABI_SLOT operator deps than what was originally intended for SLOT operator deps. In other words, anyone who is opposed to ABI_SLOT operator deps is likely to also be opposed to your proposal. Oh :(, and what is the reason to want to prevent this behavior? Looks much simpler to me than needing to use ranges for dependencies or needing to create compat packages to hide the problem :| It's close enough to ABI_SLOT that it would make more sense just to use ABI_SLOT because it's more flexible. In that case, I think it's clear we need ABI_SLOT ;) The problem is how to document it in a way people agree with including it for eapi5 :| We can just write a specification for this one feature, and ask the Council to approve it. That would be nice, if you remember, I started with elog/ecommand splitting solution to try to get this long standing issue solved soon and, since looks like each eapi takes more than a year to complete, I would really prefer to see it included in eapi5, specially after seeing that this ABI_SLOT idea was suggested years ago but the issue stalled later multiple times signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About forcing rebuilds of other packages issue
El sáb, 09-06-2012 a las 12:46 +0200, Pacho Ramos escribió: El vie, 08-06-2012 a las 12:31 -0700, Zac Medico escribió: On 06/08/2012 12:23 PM, Pacho Ramos wrote: El vie, 08-06-2012 a las 12:16 -0700, Zac Medico escribió: On 06/08/2012 01:38 AM, Pacho Ramos wrote: El jue, 07-06-2012 a las 12:33 -0700, Zac Medico escribió: On 06/07/2012 12:24 PM, Pacho Ramos wrote: El jue, 07-06-2012 a las 12:09 -0700, Zac Medico escribió: On 06/07/2012 12:00 PM, Pacho Ramos wrote: El jue, 07-06-2012 a las 19:44 +0100, Ciaran McCreesh escribió: On Thu, 07 Jun 2012 20:43:54 +0200 Pacho Ramos pa...@gentoo.org wrote: I would prefer, as a workaround, allow reverse deps to RDEPEND on glib:2.* instead. That way it would cover more cases when more than two slots are available Well, per: http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commitdiff;h=f9f7729c047300e1924ad768a49c660e12c2f906;hp=b7750e67b4772c1064543defb7df6a556f09807b looks like * usage for SLOTs would be allowed :), or I am misinterpreting it? It's not a wildcard. But it looks like a valid usage for cases like glib vs. dbus-glib/gobject-introspection I have exposed as example, and also allows us to keep SLOT over ABI_SLOT (at least for this case, not sure about others I could be missing now...) The :* operator doesn't trigger any rebuilds though. Quoting the PMS patch that you linked: * Indicates that any slot value is acceptable. In addition, for runtime dependencies, indicates that the package will not break if the matched package is uninstalled and replaced by a different matching package in a different slot. I mean, use it in conjunction with :=, one for rebuild and other to indicate any 2.x SLOT fits the normal RDEPEND (to not need to periodically update RDEPENDs or need to go back from :SLOT depends to old =category/package-version-* ways) Allowing that, we wouldn't need ABI_SLOT (at least to prevent this issue that arises with using only SLOTs for this) What you're talking about here is more similar to ABI_SLOT operator deps than what was originally intended for SLOT operator deps. In other words, anyone who is opposed to ABI_SLOT operator deps is likely to also be opposed to your proposal. Oh :(, and what is the reason to want to prevent this behavior? Looks much simpler to me than needing to use ranges for dependencies or needing to create compat packages to hide the problem :| It's close enough to ABI_SLOT that it would make more sense just to use ABI_SLOT because it's more flexible. In that case, I think it's clear we need ABI_SLOT ;) The problem is how to document it in a way people agree with including it for eapi5 :| We can just write a specification for this one feature, and ask the Council to approve it. That would be nice, if you remember, I started with elog/ecommand splitting solution to try to get this long standing issue solved soon and, since looks like each eapi takes more than a year to complete, I would really prefer to see it included in eapi5, specially after seeing that this ABI_SLOT idea was suggested years ago but the issue stalled later multiple times Also, taking into account that all affected packages should start migrating to eapi5 to really allow us to stop needing to use current tricks, would be much better to start as soon as possible instead of waiting for another eapi cycle, that would delay real solution (I mean, new eapi used by all affected packages in the tree) even more months (or years) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On Fri, 08 Jun 2012 12:31:55 -0700 Zac Medico zmed...@gentoo.org wrote: We can just write a specification for this one feature, and ask the Council to approve it. The last feature someone did that way was REQUIRED_USE, and we all know how that turned out... What you *should* do is get an implementation, then try converting lots of ebuilds with and without being able to use ABI_SLOT. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On 06/09/2012 05:15 AM, Ciaran McCreesh wrote: On Fri, 08 Jun 2012 12:31:55 -0700 Zac Medico zmed...@gentoo.org wrote: We can just write a specification for this one feature, and ask the Council to approve it. The last feature someone did that way was REQUIRED_USE, and we all know how that turned out... What you *should* do is get an implementation, then try converting lots of ebuilds with and without being able to use ABI_SLOT. Okay, so let's create an ABI_SLOT operator specification, just for testing purposes. In order to keep things as simple as possible, let's make our model as close as possible to the existing SLOT operator model. Ebuilds that do not define ABI_SLOT will be considered to have an implicit ABI_SLOT value that is equal to their SLOT value. This way, ABI_SLOT operator deps will behave identically to SLOT operator deps when ABI_SLOT is undefined. A dependency atom will have optional SLOT and ABI_SLOT parts. Using the dbus-glib depedency on glib:2 as an example [1], the dbus-glib dependency will be expressed with an atom such as dev-libs/glib:2:= and the package manager will translate that atom to dev-libs/glib:2:=2.32 at build time. So, ':' is always used to distinguish SLOT deps, and ':=' is always used to distinguish ABI_SLOT deps. Is that syntax good? [1] http://archives.gentoo.org/gentoo-dev/msg_9f2d42da278f4815f2bfe57bfc5c2de5.xml -- Thanks, Zac
Re: [gentoo-dev] About forcing rebuilds of other packages issue
El jue, 07-06-2012 a las 12:33 -0700, Zac Medico escribió: On 06/07/2012 12:24 PM, Pacho Ramos wrote: El jue, 07-06-2012 a las 12:09 -0700, Zac Medico escribió: On 06/07/2012 12:00 PM, Pacho Ramos wrote: El jue, 07-06-2012 a las 19:44 +0100, Ciaran McCreesh escribió: On Thu, 07 Jun 2012 20:43:54 +0200 Pacho Ramos pa...@gentoo.org wrote: I would prefer, as a workaround, allow reverse deps to RDEPEND on glib:2.* instead. That way it would cover more cases when more than two slots are available Well, per: http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commitdiff;h=f9f7729c047300e1924ad768a49c660e12c2f906;hp=b7750e67b4772c1064543defb7df6a556f09807b looks like * usage for SLOTs would be allowed :), or I am misinterpreting it? It's not a wildcard. But it looks like a valid usage for cases like glib vs. dbus-glib/gobject-introspection I have exposed as example, and also allows us to keep SLOT over ABI_SLOT (at least for this case, not sure about others I could be missing now...) The :* operator doesn't trigger any rebuilds though. Quoting the PMS patch that you linked: * Indicates that any slot value is acceptable. In addition, for runtime dependencies, indicates that the package will not break if the matched package is uninstalled and replaced by a different matching package in a different slot. I mean, use it in conjunction with :=, one for rebuild and other to indicate any 2.x SLOT fits the normal RDEPEND (to not need to periodically update RDEPENDs or need to go back from :SLOT depends to old =category/package-version-* ways) Allowing that, we wouldn't need ABI_SLOT (at least to prevent this issue that arises with using only SLOTs for this) What you're talking about here is more similar to ABI_SLOT operator deps than what was originally intended for SLOT operator deps. In other words, anyone who is opposed to ABI_SLOT operator deps is likely to also be opposed to your proposal. Oh :(, and what is the reason to want to prevent this behavior? Looks much simpler to me than needing to use ranges for dependencies or needing to create compat packages to hide the problem :| signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On 06/08/2012 01:38 AM, Pacho Ramos wrote: El jue, 07-06-2012 a las 12:33 -0700, Zac Medico escribió: On 06/07/2012 12:24 PM, Pacho Ramos wrote: El jue, 07-06-2012 a las 12:09 -0700, Zac Medico escribió: On 06/07/2012 12:00 PM, Pacho Ramos wrote: El jue, 07-06-2012 a las 19:44 +0100, Ciaran McCreesh escribió: On Thu, 07 Jun 2012 20:43:54 +0200 Pacho Ramos pa...@gentoo.org wrote: I would prefer, as a workaround, allow reverse deps to RDEPEND on glib:2.* instead. That way it would cover more cases when more than two slots are available Well, per: http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commitdiff;h=f9f7729c047300e1924ad768a49c660e12c2f906;hp=b7750e67b4772c1064543defb7df6a556f09807b looks like * usage for SLOTs would be allowed :), or I am misinterpreting it? It's not a wildcard. But it looks like a valid usage for cases like glib vs. dbus-glib/gobject-introspection I have exposed as example, and also allows us to keep SLOT over ABI_SLOT (at least for this case, not sure about others I could be missing now...) The :* operator doesn't trigger any rebuilds though. Quoting the PMS patch that you linked: * Indicates that any slot value is acceptable. In addition, for runtime dependencies, indicates that the package will not break if the matched package is uninstalled and replaced by a different matching package in a different slot. I mean, use it in conjunction with :=, one for rebuild and other to indicate any 2.x SLOT fits the normal RDEPEND (to not need to periodically update RDEPENDs or need to go back from :SLOT depends to old =category/package-version-* ways) Allowing that, we wouldn't need ABI_SLOT (at least to prevent this issue that arises with using only SLOTs for this) What you're talking about here is more similar to ABI_SLOT operator deps than what was originally intended for SLOT operator deps. In other words, anyone who is opposed to ABI_SLOT operator deps is likely to also be opposed to your proposal. Oh :(, and what is the reason to want to prevent this behavior? Looks much simpler to me than needing to use ranges for dependencies or needing to create compat packages to hide the problem :| It's close enough to ABI_SLOT that it would make more sense just to use ABI_SLOT because it's more flexible. -- Thanks, Zac
Re: [gentoo-dev] About forcing rebuilds of other packages issue
El vie, 08-06-2012 a las 12:16 -0700, Zac Medico escribió: On 06/08/2012 01:38 AM, Pacho Ramos wrote: El jue, 07-06-2012 a las 12:33 -0700, Zac Medico escribió: On 06/07/2012 12:24 PM, Pacho Ramos wrote: El jue, 07-06-2012 a las 12:09 -0700, Zac Medico escribió: On 06/07/2012 12:00 PM, Pacho Ramos wrote: El jue, 07-06-2012 a las 19:44 +0100, Ciaran McCreesh escribió: On Thu, 07 Jun 2012 20:43:54 +0200 Pacho Ramos pa...@gentoo.org wrote: I would prefer, as a workaround, allow reverse deps to RDEPEND on glib:2.* instead. That way it would cover more cases when more than two slots are available Well, per: http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commitdiff;h=f9f7729c047300e1924ad768a49c660e12c2f906;hp=b7750e67b4772c1064543defb7df6a556f09807b looks like * usage for SLOTs would be allowed :), or I am misinterpreting it? It's not a wildcard. But it looks like a valid usage for cases like glib vs. dbus-glib/gobject-introspection I have exposed as example, and also allows us to keep SLOT over ABI_SLOT (at least for this case, not sure about others I could be missing now...) The :* operator doesn't trigger any rebuilds though. Quoting the PMS patch that you linked: * Indicates that any slot value is acceptable. In addition, for runtime dependencies, indicates that the package will not break if the matched package is uninstalled and replaced by a different matching package in a different slot. I mean, use it in conjunction with :=, one for rebuild and other to indicate any 2.x SLOT fits the normal RDEPEND (to not need to periodically update RDEPENDs or need to go back from :SLOT depends to old =category/package-version-* ways) Allowing that, we wouldn't need ABI_SLOT (at least to prevent this issue that arises with using only SLOTs for this) What you're talking about here is more similar to ABI_SLOT operator deps than what was originally intended for SLOT operator deps. In other words, anyone who is opposed to ABI_SLOT operator deps is likely to also be opposed to your proposal. Oh :(, and what is the reason to want to prevent this behavior? Looks much simpler to me than needing to use ranges for dependencies or needing to create compat packages to hide the problem :| It's close enough to ABI_SLOT that it would make more sense just to use ABI_SLOT because it's more flexible. In that case, I think it's clear we need ABI_SLOT ;) The problem is how to document it in a way people agree with including it for eapi5 :| signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About forcing rebuilds of other packages issue
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/06/12 03:23 PM, Pacho Ramos wrote: El vie, 08-06-2012 a las 12:16 -0700, Zac Medico escribió: It's close enough to ABI_SLOT that it would make more sense just to use ABI_SLOT because it's more flexible. In that case, I think it's clear we need ABI_SLOT ;) The problem is how to document it in a way people agree with including it for eapi5 :| If there's too much resistance it could wait for EAPI=6 couldn't it? Essentially we'd all just agree that these issues, which ABI_SLOT will be needed to effectively resolve, will have to wait and we shouldn't do vast tree-wide workarounds like SLOT every library in existence and require all consumers to have ':=' slot operators on their deps. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iF4EAREIAAYFAk/SUwwACgkQ2ugaI38ACPCWtQEArkrEsVYa7/tJ8UT1pDBhDhsJ +jdMEsbJa++3bWat9TUA/1YoEaOp3cGShNDraFv+cLQl2Qf+hpz3K1AasJVstQwa =Nqw/ -END PGP SIGNATURE-
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On 06/08/2012 12:23 PM, Pacho Ramos wrote: El vie, 08-06-2012 a las 12:16 -0700, Zac Medico escribió: On 06/08/2012 01:38 AM, Pacho Ramos wrote: El jue, 07-06-2012 a las 12:33 -0700, Zac Medico escribió: On 06/07/2012 12:24 PM, Pacho Ramos wrote: El jue, 07-06-2012 a las 12:09 -0700, Zac Medico escribió: On 06/07/2012 12:00 PM, Pacho Ramos wrote: El jue, 07-06-2012 a las 19:44 +0100, Ciaran McCreesh escribió: On Thu, 07 Jun 2012 20:43:54 +0200 Pacho Ramos pa...@gentoo.org wrote: I would prefer, as a workaround, allow reverse deps to RDEPEND on glib:2.* instead. That way it would cover more cases when more than two slots are available Well, per: http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commitdiff;h=f9f7729c047300e1924ad768a49c660e12c2f906;hp=b7750e67b4772c1064543defb7df6a556f09807b looks like * usage for SLOTs would be allowed :), or I am misinterpreting it? It's not a wildcard. But it looks like a valid usage for cases like glib vs. dbus-glib/gobject-introspection I have exposed as example, and also allows us to keep SLOT over ABI_SLOT (at least for this case, not sure about others I could be missing now...) The :* operator doesn't trigger any rebuilds though. Quoting the PMS patch that you linked: * Indicates that any slot value is acceptable. In addition, for runtime dependencies, indicates that the package will not break if the matched package is uninstalled and replaced by a different matching package in a different slot. I mean, use it in conjunction with :=, one for rebuild and other to indicate any 2.x SLOT fits the normal RDEPEND (to not need to periodically update RDEPENDs or need to go back from :SLOT depends to old =category/package-version-* ways) Allowing that, we wouldn't need ABI_SLOT (at least to prevent this issue that arises with using only SLOTs for this) What you're talking about here is more similar to ABI_SLOT operator deps than what was originally intended for SLOT operator deps. In other words, anyone who is opposed to ABI_SLOT operator deps is likely to also be opposed to your proposal. Oh :(, and what is the reason to want to prevent this behavior? Looks much simpler to me than needing to use ranges for dependencies or needing to create compat packages to hide the problem :| It's close enough to ABI_SLOT that it would make more sense just to use ABI_SLOT because it's more flexible. In that case, I think it's clear we need ABI_SLOT ;) The problem is how to document it in a way people agree with including it for eapi5 :| We can just write a specification for this one feature, and ask the Council to approve it. -- Thanks, Zac
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On Wed, 06 Jun 2012 14:45:55 -0700 Zac Medico zmed...@gentoo.org wrote: Can you explain how Exherbo is handling dbus-glib rebuilds after glib:2 updates? Badly, most likely. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On Wed, Jun 06, 2012 at 05:43:49PM -0700, Zac Medico wrote: On 06/06/2012 12:23 PM, Ciaran McCreesh wrote: On Wed, 06 Jun 2012 21:16:05 +0200 Pacho Ramos pa...@gentoo.org wrote: Well, I think reading this thread is more or less clear what it would be supposed to do, also Zac suggested it and looks to have an idea about what should it do. There's a big leap from more or less clear and an idea to the kind of knowledge we want to have. Think REQUIRED_USE for how this can go wrong... If you think ABI_SLOT is essential, why not try implementing it and trying it out in a large number of packages, and reporting your results? It's pretty close to the SLOT operator model, and it seems like it should work fine. We can deploy EAPI 5_pre1 with ABI_SLOT support, and test it in an overlay before we include it in the final EAPI 5. I'd prefer you nailing down the details a bit more before slipping it into an EAPI called 5_pre1; aside from usual complaints, frankly I'd rather not have to figure out the design of it via raiding the patches out of portage history ;) If we're going to do this, there should be a way to represent the direction of compatibility. Might be overthinking it, but consider upgrades where new API is added; this does *not* break ABI, it extends it. Going in reverse however *would* break ABI for anything that was using the new additions. This issue can be avoided via usage of version operators w/ appropriate slot binding deps, just seems hanky in light of what we're talking about. I'm perfectly fine w/ ABI_SLOT and SLOT (I proposed a similar thing in '06/'07); I'd however suggest ensuring there is some buy in from devs on that one since that was the main argument against it in the past. That argument may no longer apply, but should be checked imo. ~harring
Re: [gentoo-dev] About forcing rebuilds of other packages issue
El mié, 06-06-2012 a las 14:59 -0700, Brian Harring escribió: On Tue, Jun 05, 2012 at 07:18:01PM -0700, Zac Medico wrote: On 06/05/2012 05:51 PM, Michael Weber wrote: Is there any chance to detect this ZLIB_VERSION problem with revdep-rebuild (worst case: add a list of possibly broken packages with tests)? I'd suggest a special ebuild phase to check for ABI changes, like the pre_pkg_preinst_abi_check phase suggested here: https://bugs.gentoo.org/show_bug.cgi?id=192319#c20 Same thing I said in '07; I don't have a problem w/ hooks for ebuilds to specify additional QA checks, but this *cannot* be the user's end solution- it needs to be purely for making it easier for devs to spot their screwups. In other words, revdep-rebuild shouldn't be involved; this should spot/complain that zlib (for example) changed abi w/out a matching metadata setting/whatever, rather than having checks done in the consumers. Using this for anything other than a QA check of the originating package, basically has an end result of us going towards a non-deterministic resolution model- which is a clusterfuck, frankly. ~harring Personally, my intention was exactly that: use that check to allow devs to detect the problem and commit a proper ebuild (this test could even be fatal to really enforce developers to not miss it) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On 06/07/2012 01:24 AM, Brian Harring wrote: On Wed, Jun 06, 2012 at 05:43:49PM -0700, Zac Medico wrote: On 06/06/2012 12:23 PM, Ciaran McCreesh wrote: On Wed, 06 Jun 2012 21:16:05 +0200 Pacho Ramos pa...@gentoo.org wrote: Well, I think reading this thread is more or less clear what it would be supposed to do, also Zac suggested it and looks to have an idea about what should it do. There's a big leap from more or less clear and an idea to the kind of knowledge we want to have. Think REQUIRED_USE for how this can go wrong... If you think ABI_SLOT is essential, why not try implementing it and trying it out in a large number of packages, and reporting your results? It's pretty close to the SLOT operator model, and it seems like it should work fine. We can deploy EAPI 5_pre1 with ABI_SLOT support, and test it in an overlay before we include it in the final EAPI 5. I'd prefer you nailing down the details a bit more before slipping it into an EAPI called 5_pre1; aside from usual complaints, frankly I'd rather not have to figure out the design of it via raiding the patches out of portage history ;) Ciaran already has SLOT operators in his eapi-5 branch of PMS. Maybe we can convince him to change it to ABI_SLOT operators. If we're going to do this, there should be a way to represent the direction of compatibility. Might be overthinking it, but consider upgrades where new API is added; this does *not* break ABI, it extends it. Going in reverse however *would* break ABI for anything that was using the new additions. This issue can be avoided via usage of version operators w/ appropriate slot binding deps, just seems hanky in light of what we're talking about. That might be nice, but it also complicates things a bit. We might stand a better chance of getting Ciaran to cooperate if we keep it simpler and stay closer to the SLOT operator model. I'm perfectly fine w/ ABI_SLOT and SLOT (I proposed a similar thing in '06/'07); I'd however suggest ensuring there is some buy in from devs on that one since that was the main argument against it in the past. I can imagine that ABI_SLOT operator deps will be a lot more popular than SLOT operator deps, since ABI_SLOT operator deps will accommodate the common practice of allowing ABI changes within a particular SLOT. -- Thanks, Zac
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On 06/06/2012 10:28 PM, Ciaran McCreesh wrote: On Wed, 06 Jun 2012 14:21:40 -0700 Zac Medico zmed...@gentoo.org wrote: You'd have a slot per ABI, and be encouraged to allow multiple versions of glib to be installed in parallel. If you really couldn't do that (and you should think very carefully before saying you can't, since this directly affects users in a huge way), you can make the slots block each other. It seems like you're trying to make glib fit your SLOT operator model, even though it's a natural fit for the ABI_SLOT operator model. No, I'm trying to strongly encourage people to make proper use of slots to avoid having mass breakages and annoyances on user systems, even if it means more work for developers. But aren't you also trying to make them deviate from upstreams' release models? Broken linkage due to an upgrade really shouldn't happen. It's certainly not ideal, but wouldn't it be useful to have the flexibility to accommodate it? Let's be practical. -- Thanks, Zac
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On Thu, 07 Jun 2012 09:43:32 -0700 Zac Medico zmed...@gentoo.org wrote: I can imagine that ABI_SLOT operator deps will be a lot more popular than SLOT operator deps, since ABI_SLOT operator deps will accommodate the common practice of allowing ABI changes within a particular SLOT. You're missing out on a brilliant opportunity to encourage developers put in a bit more work to save users a huge amount of pain here. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On 06/06/2012 11:12 PM, Ciaran McCreesh wrote: On Wed, 06 Jun 2012 14:45:55 -0700 Zac Medico zmed...@gentoo.org wrote: Can you explain how Exherbo is handling dbus-glib rebuilds after glib:2 updates? Badly, most likely. And, I suspect that they'd be handling with ABI_SLOT operator deps, if they were available. -- Thanks, Zac
Re: [gentoo-dev] About forcing rebuilds of other packages issue
El jue, 07-06-2012 a las 18:40 +0100, Ciaran McCreesh escribió: On Thu, 07 Jun 2012 09:43:32 -0700 Zac Medico zmed...@gentoo.org wrote: I can imagine that ABI_SLOT operator deps will be a lot more popular than SLOT operator deps, since ABI_SLOT operator deps will accommodate the common practice of allowing ABI changes within a particular SLOT. You're missing out on a brilliant opportunity to encourage developers put in a bit more work to save users a huge amount of pain here. Won't be possible to encourage developers to make that bit more work when that work is not so bit. Of course, I understand there are probably some valid cases when situation can (and should) be improved, but I still fail to see the advantage of allowing parallel installation for glib, xorg-server... taking care their reverse dependencies simply need a rebuild to work with latest ABIs and, then, users should anyway need to remove that old slots once reverse deps are rebuilt against latest slot as we wouldn't support setups where people is lazy to rebuild and have, for example, x11 drivers built against xorg-server-1.9.5-r1 even having 1.11.2-r2 installed in parallel. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About forcing rebuilds of other packages issue
El jue, 07-06-2012 a las 10:42 -0700, Zac Medico escribió: On 06/06/2012 10:28 PM, Ciaran McCreesh wrote: On Wed, 06 Jun 2012 14:21:40 -0700 Zac Medico zmed...@gentoo.org wrote: You'd have a slot per ABI, and be encouraged to allow multiple versions of glib to be installed in parallel. If you really couldn't do that (and you should think very carefully before saying you can't, since this directly affects users in a huge way), you can make the slots block each other. It seems like you're trying to make glib fit your SLOT operator model, even though it's a natural fit for the ABI_SLOT operator model. No, I'm trying to strongly encourage people to make proper use of slots to avoid having mass breakages and annoyances on user systems, even if it means more work for developers. But aren't you also trying to make them deviate from upstreams' release models? Broken linkage due to an upgrade really shouldn't happen. It's certainly not ideal, but wouldn't it be useful to have the flexibility to accommodate it? Let's be practical. Also think we are not able to fix that broken linkage problems alone, even distributions supplying precompiled packages need to rebuild their packages against latest version due that breakages before releasing new packages to the users. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On 06/07/2012 10:40 AM, Ciaran McCreesh wrote: On Thu, 07 Jun 2012 09:43:32 -0700 Zac Medico zmed...@gentoo.org wrote: I can imagine that ABI_SLOT operator deps will be a lot more popular than SLOT operator deps, since ABI_SLOT operator deps will accommodate the common practice of allowing ABI changes within a particular SLOT. You're missing out on a brilliant opportunity to encourage developers put in a bit more work to save users a huge amount of pain here. What about cases like the dbus-glib and glib:2 dependency, where it's just too much trouble to use SLOT operator deps? Wouldn't it be better to have a little flexibility, so that we can accommodate more packages? As a workaround for SLOT operator deps, I suppose that glib:1 could be split into a separate glib-legacy package, in order to facilitate the use of SLOT operator dependencies in dbus-glib. That way, it would be easy to match glib-2.x and not have to worry about trying not to match glib-1.x. -- Thanks, Zac
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On Thu, 07 Jun 2012 09:43:32 -0700 Zac Medico zmed...@gentoo.org wrote: On 06/07/2012 01:24 AM, Brian Harring wrote: On Wed, Jun 06, 2012 at 05:43:49PM -0700, Zac Medico wrote: On 06/06/2012 12:23 PM, Ciaran McCreesh wrote: On Wed, 06 Jun 2012 21:16:05 +0200 Pacho Ramos pa...@gentoo.org wrote: Well, I think reading this thread is more or less clear what it would be supposed to do, also Zac suggested it and looks to have an idea about what should it do. There's a big leap from more or less clear and an idea to the kind of knowledge we want to have. Think REQUIRED_USE for how this can go wrong... If you think ABI_SLOT is essential, why not try implementing it and trying it out in a large number of packages, and reporting your results? It's pretty close to the SLOT operator model, and it seems like it should work fine. We can deploy EAPI 5_pre1 with ABI_SLOT support, and test it in an overlay before we include it in the final EAPI 5. I'd prefer you nailing down the details a bit more before slipping it into an EAPI called 5_pre1; aside from usual complaints, frankly I'd rather not have to figure out the design of it via raiding the patches out of portage history ;) Ciaran already has SLOT operators in his eapi-5 branch of PMS. Maybe we can convince him to change it to ABI_SLOT operators. Whether we can convince Ciaran to change the wording of a feature in a draft document is utterly irrelevant. SLOT operator deps solve a large class of issues and wont get in the way of solving the ranged dep problem in a later step, be it ABI_SLOT or something more generic. I'm all for getting SLOT operators into EAPI-5 as actually already intended for earlier EAPIs. EAPI 5 was supposed to be a quick EAPI so don't let us delay the whole thing because of that. If we're going to do this, there should be a way to represent the direction of compatibility. Might be overthinking it, but consider upgrades where new API is added; this does *not* break ABI, it extends it. Going in reverse however *would* break ABI for anything that was using the new additions. This issue can be avoided via usage of version operators w/ appropriate slot binding deps, just seems hanky in light of what we're talking about. That might be nice, but it also complicates things a bit. We might stand a better chance of getting Ciaran to cooperate if we keep it simpler and stay closer to the SLOT operator model. Again, it's not about getting someone to cooperate. Something that you comment with that might be nice isn't ready for inclusion into EAPI 5. I'm perfectly fine w/ ABI_SLOT and SLOT (I proposed a similar thing in '06/'07); I'd however suggest ensuring there is some buy in from devs on that one since that was the main argument against it in the past. I can imagine that ABI_SLOT operator deps will be a lot more popular than SLOT operator deps, since ABI_SLOT operator deps will accommodate the common practice of allowing ABI changes within a particular SLOT. What for? So we won't ever get rid of revdep-rebuild resp. @preserved-libs? Except for the ranged dep problem I don't see any additional benefit but potential drawbacks. Please correct me where I'm wrong. Cheers. signature.asc Description: PGP signature
Re: [gentoo-dev] About forcing rebuilds of other packages issue
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07.06.2012 19:47, Zac Medico wrote: And, I suspect that they'd be handling with ABI_SLOT operator deps, if they were available. No, we wouldn't. Best regards, Wulf -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/Q7TgACgkQnuVXRcSi+5qDGwCgyRCGz13xuzCCB0htW4IalqJM eqIAn2lJRsfQUcoJ+B/iYioyPhN7oU0C =tZkw -END PGP SIGNATURE-
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On Thu, 07 Jun 2012 11:03:25 -0700 Zac Medico zmed...@gentoo.org wrote: You're missing out on a brilliant opportunity to encourage developers put in a bit more work to save users a huge amount of pain here. What about cases like the dbus-glib and glib:2 dependency, where it's just too much trouble to use SLOT operator deps? Wouldn't it be better to have a little flexibility, so that we can accommodate more packages? Then if it really is too much trouble, which is another way of saying it's a thousand times more work for a developer to get it right than it is for a user to deal with it, you can use blockers. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On Thu, 07 Jun 2012 10:42:29 -0700 Zac Medico zmed...@gentoo.org wrote: It seems like you're trying to make glib fit your SLOT operator model, even though it's a natural fit for the ABI_SLOT operator model. No, I'm trying to strongly encourage people to make proper use of slots to avoid having mass breakages and annoyances on user systems, even if it means more work for developers. But aren't you also trying to make them deviate from upstreams' release models? Only if upstream are cowboys who go out of their way to make it hard to slot things. Broken linkage due to an upgrade really shouldn't happen. It's certainly not ideal, but wouldn't it be useful to have the flexibility to accommodate it? Let's be practical. Blockers plus SLOT provides that flexibility. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] About forcing rebuilds of other packages issue
El jue, 07-06-2012 a las 20:04 +0200, Wulf C. Krueger escribió: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07.06.2012 19:47, Zac Medico wrote: And, I suspect that they'd be handling with ABI_SLOT operator deps, if they were available. No, we wouldn't. Best regards, Wulf Talk by yourself please signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About forcing rebuilds of other packages issue
El jue, 07-06-2012 a las 11:03 -0700, Zac Medico escribió: On 06/07/2012 10:40 AM, Ciaran McCreesh wrote: On Thu, 07 Jun 2012 09:43:32 -0700 Zac Medico zmed...@gentoo.org wrote: I can imagine that ABI_SLOT operator deps will be a lot more popular than SLOT operator deps, since ABI_SLOT operator deps will accommodate the common practice of allowing ABI changes within a particular SLOT. You're missing out on a brilliant opportunity to encourage developers put in a bit more work to save users a huge amount of pain here. What about cases like the dbus-glib and glib:2 dependency, where it's just too much trouble to use SLOT operator deps? Wouldn't it be better to have a little flexibility, so that we can accommodate more packages? As a workaround for SLOT operator deps, I suppose that glib:1 could be split into a separate glib-legacy package, in order to facilitate the use of SLOT operator dependencies in dbus-glib. That way, it would be easy to match glib-2.x and not have to worry about trying not to match glib-1.x. I would prefer, as a workaround, allow reverse deps to RDEPEND on glib:2.* instead. That way it would cover more cases when more than two slots are available signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On Thu, 07 Jun 2012 10:47:19 -0700 Zac Medico zmed...@gentoo.org wrote: On 06/06/2012 11:12 PM, Ciaran McCreesh wrote: On Wed, 06 Jun 2012 14:45:55 -0700 Zac Medico zmed...@gentoo.org wrote: Can you explain how Exherbo is handling dbus-glib rebuilds after glib:2 updates? Badly, most likely. And, I suspect that they'd be handling with ABI_SLOT operator deps, if they were available. Nope. They'd be handling it with something known as 'parts' (which is a way of removing a subset of an installed package's contents and turning off a subset of its option flags), plus SLOT and option dependencies. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On 06/07/2012 11:04 AM, Ralph Sennhauser wrote: On Thu, 07 Jun 2012 09:43:32 -0700 Zac Medico zmed...@gentoo.org wrote: On 06/07/2012 01:24 AM, Brian Harring wrote: On Wed, Jun 06, 2012 at 05:43:49PM -0700, Zac Medico wrote: On 06/06/2012 12:23 PM, Ciaran McCreesh wrote: On Wed, 06 Jun 2012 21:16:05 +0200 Pacho Ramos pa...@gentoo.org wrote: Well, I think reading this thread is more or less clear what it would be supposed to do, also Zac suggested it and looks to have an idea about what should it do. There's a big leap from more or less clear and an idea to the kind of knowledge we want to have. Think REQUIRED_USE for how this can go wrong... If you think ABI_SLOT is essential, why not try implementing it and trying it out in a large number of packages, and reporting your results? It's pretty close to the SLOT operator model, and it seems like it should work fine. We can deploy EAPI 5_pre1 with ABI_SLOT support, and test it in an overlay before we include it in the final EAPI 5. I'd prefer you nailing down the details a bit more before slipping it into an EAPI called 5_pre1; aside from usual complaints, frankly I'd rather not have to figure out the design of it via raiding the patches out of portage history ;) Ciaran already has SLOT operators in his eapi-5 branch of PMS. Maybe we can convince him to change it to ABI_SLOT operators. Whether we can convince Ciaran to change the wording of a feature in a draft document is utterly irrelevant. SLOT operator deps solve a large class of issues and wont get in the way of solving the ranged dep problem in a later step, be it ABI_SLOT or something more generic. I'm all for getting SLOT operators into EAPI-5 as actually already intended for earlier EAPIs. EAPI 5 was supposed to be a quick EAPI so don't let us delay the whole thing because of that. Delay doesn't concern be so much. If SLOT operator deps are the best that we can all agree on for now though, then I can accept that. -- Thanks, Zac
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On 06/07/2012 11:13 AM, Ciaran McCreesh wrote: On Thu, 07 Jun 2012 10:47:19 -0700 Zac Medico zmed...@gentoo.org wrote: On 06/06/2012 11:12 PM, Ciaran McCreesh wrote: On Wed, 06 Jun 2012 14:45:55 -0700 Zac Medico zmed...@gentoo.org wrote: Can you explain how Exherbo is handling dbus-glib rebuilds after glib:2 updates? Badly, most likely. And, I suspect that they'd be handling with ABI_SLOT operator deps, if they were available. Nope. They'd be handling it with something known as 'parts' (which is a way of removing a subset of an installed package's contents and turning off a subset of its option flags), plus SLOT and option dependencies. That sounds nice. Maybe we can do that in EAPI 6. -- Thanks, Zac
Re: [gentoo-dev] About forcing rebuilds of other packages issue
El jue, 07-06-2012 a las 20:16 +0200, Pacho Ramos escribió: El jue, 07-06-2012 a las 11:03 -0700, Zac Medico escribió: On 06/07/2012 10:40 AM, Ciaran McCreesh wrote: On Thu, 07 Jun 2012 09:43:32 -0700 Zac Medico zmed...@gentoo.org wrote: I can imagine that ABI_SLOT operator deps will be a lot more popular than SLOT operator deps, since ABI_SLOT operator deps will accommodate the common practice of allowing ABI changes within a particular SLOT. You're missing out on a brilliant opportunity to encourage developers put in a bit more work to save users a huge amount of pain here. What about cases like the dbus-glib and glib:2 dependency, where it's just too much trouble to use SLOT operator deps? Wouldn't it be better to have a little flexibility, so that we can accommodate more packages? As a workaround for SLOT operator deps, I suppose that glib:1 could be split into a separate glib-legacy package, in order to facilitate the use of SLOT operator dependencies in dbus-glib. That way, it would be easy to match glib-2.x and not have to worry about trying not to match glib-1.x. I would prefer, as a workaround, allow reverse deps to RDEPEND on glib:2.* instead. That way it would cover more cases when more than two slots are available Well, per: http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commitdiff;h=f9f7729c047300e1924ad768a49c660e12c2f906;hp=b7750e67b4772c1064543defb7df6a556f09807b looks like * usage for SLOTs would be allowed :), or I am misinterpreting it? signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On Thu, 07 Jun 2012 20:43:54 +0200 Pacho Ramos pa...@gentoo.org wrote: I would prefer, as a workaround, allow reverse deps to RDEPEND on glib:2.* instead. That way it would cover more cases when more than two slots are available Well, per: http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commitdiff;h=f9f7729c047300e1924ad768a49c660e12c2f906;hp=b7750e67b4772c1064543defb7df6a556f09807b looks like * usage for SLOTs would be allowed :), or I am misinterpreting it? It's not a wildcard. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] About forcing rebuilds of other packages issue
El jue, 07-06-2012 a las 19:44 +0100, Ciaran McCreesh escribió: On Thu, 07 Jun 2012 20:43:54 +0200 Pacho Ramos pa...@gentoo.org wrote: I would prefer, as a workaround, allow reverse deps to RDEPEND on glib:2.* instead. That way it would cover more cases when more than two slots are available Well, per: http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commitdiff;h=f9f7729c047300e1924ad768a49c660e12c2f906;hp=b7750e67b4772c1064543defb7df6a556f09807b looks like * usage for SLOTs would be allowed :), or I am misinterpreting it? It's not a wildcard. But it looks like a valid usage for cases like glib vs. dbus-glib/gobject-introspection I have exposed as example, and also allows us to keep SLOT over ABI_SLOT (at least for this case, not sure about others I could be missing now...) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On 06/07/2012 12:00 PM, Pacho Ramos wrote: El jue, 07-06-2012 a las 19:44 +0100, Ciaran McCreesh escribió: On Thu, 07 Jun 2012 20:43:54 +0200 Pacho Ramos pa...@gentoo.org wrote: I would prefer, as a workaround, allow reverse deps to RDEPEND on glib:2.* instead. That way it would cover more cases when more than two slots are available Well, per: http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commitdiff;h=f9f7729c047300e1924ad768a49c660e12c2f906;hp=b7750e67b4772c1064543defb7df6a556f09807b looks like * usage for SLOTs would be allowed :), or I am misinterpreting it? It's not a wildcard. But it looks like a valid usage for cases like glib vs. dbus-glib/gobject-introspection I have exposed as example, and also allows us to keep SLOT over ABI_SLOT (at least for this case, not sure about others I could be missing now...) The :* operator doesn't trigger any rebuilds though. Quoting the PMS patch that you linked: * Indicates that any slot value is acceptable. In addition, for runtime dependencies, indicates that the package will not break if the matched package is uninstalled and replaced by a different matching package in a different slot. -- Thanks, Zac
Re: [gentoo-dev] About forcing rebuilds of other packages issue
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/06/12 03:00 PM, Pacho Ramos wrote: El jue, 07-06-2012 a las 19:44 +0100, Ciaran McCreesh escribió: On Thu, 07 Jun 2012 20:43:54 +0200 Pacho Ramos pa...@gentoo.org wrote: I would prefer, as a workaround, allow reverse deps to RDEPEND on glib:2.* instead. That way it would cover more cases when more than two slots are available Well, per: http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commitdiff;h=f9f7729c047300e1924ad768a49c660e12c2f906;hp=b7750e67b4772c1064543defb7df6a556f09807b looks like * usage for SLOTs would be allowed :), or I am misinterpreting it? It's not a wildcard. But it looks like a valid usage for cases like glib vs. dbus-glib/gobject-introspection I have exposed as example, and also allows us to keep SLOT over ABI_SLOT (at least for this case, not sure about others I could be missing now...) How is the case of something like libpng going to be handled, where we only support one API (and so only one SLOT)? Either in the proposed ABI_SLOT thing or when using slot operators? For the slot-operator case, will every consumer of libpng be forced to change their dep to libpng:= to ensure they get rebuilt when libpng bumps from 1.5 to 1.6?? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iF4EAREIAAYFAk/Q/XsACgkQ2ugaI38ACPCxWQEAgkx7C2PBK/awXvfA3RFolZQD 2K7G7cBboDvDexn/JogA/0W/ke62zz7Mtk/i6WLATIaUYRQ+8ViK2Y4J8n4C3yVZ =SQX9 -END PGP SIGNATURE-
Re: [gentoo-dev] About forcing rebuilds of other packages issue
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 07 Jun 2012 15:14:03 -0400 Ian Stakenvicius a...@gentoo.org wrote: How is the case of something like libpng going to be handled, where we only support one API (and so only one SLOT)? Either in the proposed ABI_SLOT thing or when using slot operators? Ideally, by you putting in the work and supporting more than one API, since doing so vastly improves the user experience. Failing that, SLOT plus blockers. Then if it turns out that really doesn't work (and it's not just developers being utterly lazy), either ABI_SLOT or parts in a future EAPI. For the slot-operator case, will every consumer of libpng be forced to change their dep to libpng:= to ensure they get rebuilt when libpng bumps from 1.5 to 1.6?? Every consumer of libpng that wants to improve from the current situation, yes. - -- Ciaran McCreesh -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAk/Q/dMACgkQ96zL6DUtXhFlgQCaAr/9xTL8/bwTHbqud5ETo1fN T64An077XiZVmdP+/76KBTdRVlaDa4U2 =se/J -END PGP SIGNATURE-
Re: [gentoo-dev] About forcing rebuilds of other packages issue
El jue, 07-06-2012 a las 12:09 -0700, Zac Medico escribió: On 06/07/2012 12:00 PM, Pacho Ramos wrote: El jue, 07-06-2012 a las 19:44 +0100, Ciaran McCreesh escribió: On Thu, 07 Jun 2012 20:43:54 +0200 Pacho Ramos pa...@gentoo.org wrote: I would prefer, as a workaround, allow reverse deps to RDEPEND on glib:2.* instead. That way it would cover more cases when more than two slots are available Well, per: http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commitdiff;h=f9f7729c047300e1924ad768a49c660e12c2f906;hp=b7750e67b4772c1064543defb7df6a556f09807b looks like * usage for SLOTs would be allowed :), or I am misinterpreting it? It's not a wildcard. But it looks like a valid usage for cases like glib vs. dbus-glib/gobject-introspection I have exposed as example, and also allows us to keep SLOT over ABI_SLOT (at least for this case, not sure about others I could be missing now...) The :* operator doesn't trigger any rebuilds though. Quoting the PMS patch that you linked: * Indicates that any slot value is acceptable. In addition, for runtime dependencies, indicates that the package will not break if the matched package is uninstalled and replaced by a different matching package in a different slot. I mean, use it in conjunction with :=, one for rebuild and other to indicate any 2.x SLOT fits the normal RDEPEND (to not need to periodically update RDEPENDs or need to go back from :SLOT depends to old =category/package-version-* ways) Allowing that, we wouldn't need ABI_SLOT (at least to prevent this issue that arises with using only SLOTs for this) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On 06/07/2012 12:24 PM, Pacho Ramos wrote: El jue, 07-06-2012 a las 12:09 -0700, Zac Medico escribió: On 06/07/2012 12:00 PM, Pacho Ramos wrote: El jue, 07-06-2012 a las 19:44 +0100, Ciaran McCreesh escribió: On Thu, 07 Jun 2012 20:43:54 +0200 Pacho Ramos pa...@gentoo.org wrote: I would prefer, as a workaround, allow reverse deps to RDEPEND on glib:2.* instead. That way it would cover more cases when more than two slots are available Well, per: http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commitdiff;h=f9f7729c047300e1924ad768a49c660e12c2f906;hp=b7750e67b4772c1064543defb7df6a556f09807b looks like * usage for SLOTs would be allowed :), or I am misinterpreting it? It's not a wildcard. But it looks like a valid usage for cases like glib vs. dbus-glib/gobject-introspection I have exposed as example, and also allows us to keep SLOT over ABI_SLOT (at least for this case, not sure about others I could be missing now...) The :* operator doesn't trigger any rebuilds though. Quoting the PMS patch that you linked: * Indicates that any slot value is acceptable. In addition, for runtime dependencies, indicates that the package will not break if the matched package is uninstalled and replaced by a different matching package in a different slot. I mean, use it in conjunction with :=, one for rebuild and other to indicate any 2.x SLOT fits the normal RDEPEND (to not need to periodically update RDEPENDs or need to go back from :SLOT depends to old =category/package-version-* ways) Allowing that, we wouldn't need ABI_SLOT (at least to prevent this issue that arises with using only SLOTs for this) What you're talking about here is more similar to ABI_SLOT operator deps than what was originally intended for SLOT operator deps. In other words, anyone who is opposed to ABI_SLOT operator deps is likely to also be opposed to your proposal. -- Thanks, Zac
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On Thu, Jun 07, 2012 at 08:15:28PM +0100, Ciaran McCreesh wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 07 Jun 2012 15:14:03 -0400 Ian Stakenvicius a...@gentoo.org wrote: How is the case of something like libpng going to be handled, where we only support one API (and so only one SLOT)? Either in the proposed ABI_SLOT thing or when using slot operators? Ideally, by you putting in the work and supporting more than one API, since doing so vastly improves the user experience. Failing that, SLOT plus blockers. Then if it turns out that really doesn't work (and it's not just developers being utterly lazy), either ABI_SLOT or parts in a future EAPI. SLOT + blockers only works for API breakages; for instances where API is the same but the ABI has shifted (a lib function switching from taking a short switching to a long for example), the scheme doesn't work and rebuilding is what's required. Thing is, the API breakage bit we already have sorted; point of this whole discussion is dealing w/ the latter scenario, which slot + blockers *doesn't* address; not unless your proposal is the clusterfuck notion of modifying the ebuild providing the lib, and sticking a shite ton of blockers for every known consumer. That approach is wrong on multiple levels to say the least. For the slot-operator case, will every consumer of libpng be forced to change their dep to libpng:= to ensure they get rebuilt when libpng bumps from 1.5 to 1.6?? Every consumer of libpng that wants to improve from the current situation, yes. Just going to point something out here; you've spent a lot of time stating Someone else has to go sort these problems out- problems that in many cases are decades old. You want to enforce this hard line, you do the work. Reminder: Ebuilds sole purpose are to make integrators jobs easier. Not to enforce the views of EAPI authors, but to enable people to get shit done. ABI_SLOT should *not* be used all over the place; it's basically a corner case variable that allows integrators to work around known cranky upstreams, or generally thorny ass problems. Aka, scenarios where the slotting solution doesn't fit. Unless ciaran's plan is to step up and fix all of these offending scenarios (and keep doing so), ABI_SLOT should be landed at the same time as SLOT operators. We already know it has uses, and when it *occurs*, it's painful to deal with it- specifically at the user level. Provide the PM the neccessary data, and it can lessen that pain. ~harring
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On 06/07/2012 11:04 AM, Ralph Sennhauser wrote: On Thu, 07 Jun 2012 09:43:32 -0700 Zac Medico zmed...@gentoo.org wrote: On 06/07/2012 01:24 AM, Brian Harring wrote: I'm perfectly fine w/ ABI_SLOT and SLOT (I proposed a similar thing in '06/'07); I'd however suggest ensuring there is some buy in from devs on that one since that was the main argument against it in the past. I can imagine that ABI_SLOT operator deps will be a lot more popular than SLOT operator deps, since ABI_SLOT operator deps will accommodate the common practice of allowing ABI changes within a particular SLOT. What for? So we won't ever get rid of revdep-rebuild resp. @preserved-libs? Except for the ranged dep problem I don't see any additional benefit but potential drawbacks. Please correct me where I'm wrong. ABI_SLOT operator deps *do* allow us to get rid of revdep-rebuild, since they are usable in cases like the dbus-glib/glib:2 dependency, where SLOT operator deps are unmanageable. -- Thanks, Zac
Re: [gentoo-dev] About forcing rebuilds of other packages issue
El mar, 05-06-2012 a las 16:07 -0700, Zac Medico escribió: On 06/05/2012 06:31 AM, Pacho Ramos wrote: El mar, 05-06-2012 a las 08:44 -0400, Aaron W. Swenson escribió: The ideal solution is for the Ebuild to instruct the PMS to rebuild the dependent packages. We can have a variable called REBUILD. All packages that would need to be rebuilt can be listed in it. Only those packages that are installed would be built. The actual list of the packages to be rebuilt would be determined at dependency checking time. That way, the user can approve the rebuild of the packages. We all know what would be the ideal solution, the problem is how to implement it (and how many years we need to wait to get it working). This REBUILD variable is the first idea that pops into the head of anyone who's never worked on a dependency resolver before. It's backwards because it requires a package to have knowledge of *all* of its reverse dependencies, and it should not need to know about *any* of them. The SLOT operator dependencies that Ciaran has been advocating are very close to a good solution. However, if we want it to work with unslotted packages, then we need to introduce a separate ABI_SLOT variable as discussed here: https://bugs.gentoo.org/show_bug.cgi?id=192319#c18 It's really no more difficult to do than SLOT operator dependencies, it's more flexible, and we can do it in EAPI 5. In that case, I obviously wouldn't have any problem with that approach (it sound even better :)). Is there any place where I could get a bit more documentation about how this SLOT operator way would work? For example, how would work for rebuilding x11 drivers after updating xorg or rebuilding gobject-introspection after major glib update... Thanks a lot for the info :) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About forcing rebuilds of other packages issue
El mié, 06-06-2012 a las 06:33 +0100, Ciaran McCreesh escribió: On Tue, 05 Jun 2012 15:31:01 +0200 Pacho Ramos pa...@gentoo.org wrote: We all know what would be the ideal solution, the problem is how to implement it (and how many years we need to wait to get it working). We do? Please tell us. I was under the impression that we still didn't fully know what the problem was. Well, could you please let me know how to handle some issues already mentioned? For example: - Rebuild dbus-glib and gobject-introspection after major glib update. - Rebuild x11 drivers after xorg-update - Rebuild python/perl/ocaml stuff after python/perl/ocaml update Please take care I am simply asking your for information about how to handle it with the SLOT operator way or, at least, show me an example, because I don't know much about it. Thanks a lot for the info :) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About forcing rebuilds of other packages issue
El mié, 06-06-2012 a las 01:54 -0700, Zac Medico escribió: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/06/2012 01:46 AM, Pacho Ramos wrote: El mar, 05-06-2012 a las 19:18 -0700, Zac Medico escribió: On 06/05/2012 05:51 PM, Michael Weber wrote: Is there any chance to detect this ZLIB_VERSION problem with revdep-rebuild (worst case: add a list of possibly broken packages with tests)? I'd suggest a special ebuild phase to check for ABI changes, like the pre_pkg_preinst_abi_check phase suggested here: https://bugs.gentoo.org/show_bug.cgi?id=192319#c20 I guess, that phase would detect ABI change and package manager would know how to handle it by itself? Yeah, it would be like a warning system, do detect cases when the SLOT/ABI_SLOT were not bumped when they should have been. The idea is that the developer who's doing the version bump will see the warning and bump the SLOT/ABI_SLOT before committing the ebuild. - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/PGt4ACgkQ/ejvha5XGaMt8QCffullYkU7EQXeE7TeUri4nQya ysIAoMhPQT+rEZbxKNvMiX8qNOEndiM1 =V7Tz -END PGP SIGNATURE- And once we bump SLOT/ABI_SLOT, package manager would know about how to handle that situation and rebuild needed stuff? If we use SLOT only, I guess we would need to allow (or make more common) pulling multiple slot but all of them mutually exclusive no? I have no problem with that of course, but I thought it wasn't desired in general. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On 06/06/2012 01:28 AM, Pacho Ramos wrote: El mar, 05-06-2012 a las 16:07 -0700, Zac Medico escribió: The SLOT operator dependencies that Ciaran has been advocating are very close to a good solution. However, if we want it to work with unslotted packages, then we need to introduce a separate ABI_SLOT variable as discussed here: https://bugs.gentoo.org/show_bug.cgi?id=192319#c18 It's really no more difficult to do than SLOT operator dependencies, it's more flexible, and we can do it in EAPI 5. In that case, I obviously wouldn't have any problem with that approach (it sound even better :)). Is there any place where I could get a bit more documentation about how this SLOT operator way would work? For example, how would work for rebuilding x11 drivers after updating xorg or rebuilding gobject-introspection after major glib update... Whenever you have an ABI change, the developer doing the version bump needs to increment the SLOT (or ABI_SLOT if we use a separate variable) in the package. Packages that depend on the package with the ABI change (reverse dependencies) append a := operator to their dependency atoms, indicating that they are locked to the ABI of the SLOT that they are built against. The package manager translates the := operators into a dependencies on specific SLOTs at build time, so that when you update your system next time, it can use this information to trigger rebuilds automatically when necessary. -- Thanks, Zac
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On 06/06/2012 02:10 AM, Pacho Ramos wrote: El mié, 06-06-2012 a las 01:54 -0700, Zac Medico escribió: On 06/06/2012 01:46 AM, Pacho Ramos wrote: El mar, 05-06-2012 a las 19:18 -0700, Zac Medico escribió: On 06/05/2012 05:51 PM, Michael Weber wrote: Is there any chance to detect this ZLIB_VERSION problem with revdep-rebuild (worst case: add a list of possibly broken packages with tests)? I'd suggest a special ebuild phase to check for ABI changes, like the pre_pkg_preinst_abi_check phase suggested here: https://bugs.gentoo.org/show_bug.cgi?id=192319#c20 I guess, that phase would detect ABI change and package manager would know how to handle it by itself? Yeah, it would be like a warning system, do detect cases when the SLOT/ABI_SLOT were not bumped when they should have been. The idea is that the developer who's doing the version bump will see the warning and bump the SLOT/ABI_SLOT before committing the ebuild. And once we bump SLOT/ABI_SLOT, package manager would know about how to handle that situation and rebuild needed stuff? Right, as long as the reverse dependencies use the := SLOT operator like they're supposed to. That's how they let the package manager know that they'll need to be rebuilt when the ABI changes. If we use SLOT only, I guess we would need to allow (or make more common) pulling multiple slot but all of them mutually exclusive no? Yeah, blockers are already used like this sometimes, like for google-chrome which has mutually exclusive stable, beta, and unstable SLOTs. I have no problem with that of course, but I thought it wasn't desired in general. Well, we can always introduce a separate ABI_SLOT variable in a later EAPI, if we want. -- Thanks, Zac
Re: [gentoo-dev] About forcing rebuilds of other packages issue
El mié, 06-06-2012 a las 02:17 -0700, Zac Medico escribió: On 06/06/2012 01:28 AM, Pacho Ramos wrote: El mar, 05-06-2012 a las 16:07 -0700, Zac Medico escribió: The SLOT operator dependencies that Ciaran has been advocating are very close to a good solution. However, if we want it to work with unslotted packages, then we need to introduce a separate ABI_SLOT variable as discussed here: https://bugs.gentoo.org/show_bug.cgi?id=192319#c18 It's really no more difficult to do than SLOT operator dependencies, it's more flexible, and we can do it in EAPI 5. In that case, I obviously wouldn't have any problem with that approach (it sound even better :)). Is there any place where I could get a bit more documentation about how this SLOT operator way would work? For example, how would work for rebuilding x11 drivers after updating xorg or rebuilding gobject-introspection after major glib update... Whenever you have an ABI change, the developer doing the version bump needs to increment the SLOT (or ABI_SLOT if we use a separate variable) in the package. Packages that depend on the package with the ABI change (reverse dependencies) append a := operator to their dependency atoms, indicating that they are locked to the ABI of the SLOT that they are built against. The package manager translates the := operators into a dependencies on specific SLOTs at build time, so that when you update your system next time, it can use this information to trigger rebuilds automatically when necessary. That looks nice, only two notes: - Looks like would be more sense on distinguish between SLOT and ABI_SLOT, for example: * dbus-glib would rdepend on glib:2 * if glib:2 abi changes, we would pull a ABI_SLOT=2.32 inside glib-2 ebuild * dbus-glib rdepending on glib:=2 would get rebuilt If we would use SLOT for all the cases, how would we handle it? I mean, glib slot would be bumped to 2.32 and dbus-glib ebuilds updated to rdepend on every new slot? Or would package managers distinct between versions inside the same SLOT variable? - What would occur with packages forced to use eapi0 due backwards compat? We could probably deprecate eapis older than 5 to allow all the tree be consistent with this rebuilds forcing, but no idea what to do with system packages still needing to use eapi0 and maybe changing their ABI too :/ signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On 06/06/2012 02:48 AM, Pacho Ramos wrote: El mié, 06-06-2012 a las 02:17 -0700, Zac Medico escribió: On 06/06/2012 01:28 AM, Pacho Ramos wrote: El mar, 05-06-2012 a las 16:07 -0700, Zac Medico escribió: The SLOT operator dependencies that Ciaran has been advocating are very close to a good solution. However, if we want it to work with unslotted packages, then we need to introduce a separate ABI_SLOT variable as discussed here: https://bugs.gentoo.org/show_bug.cgi?id=192319#c18 It's really no more difficult to do than SLOT operator dependencies, it's more flexible, and we can do it in EAPI 5. In that case, I obviously wouldn't have any problem with that approach (it sound even better :)). Is there any place where I could get a bit more documentation about how this SLOT operator way would work? For example, how would work for rebuilding x11 drivers after updating xorg or rebuilding gobject-introspection after major glib update... Whenever you have an ABI change, the developer doing the version bump needs to increment the SLOT (or ABI_SLOT if we use a separate variable) in the package. Packages that depend on the package with the ABI change (reverse dependencies) append a := operator to their dependency atoms, indicating that they are locked to the ABI of the SLOT that they are built against. The package manager translates the := operators into a dependencies on specific SLOTs at build time, so that when you update your system next time, it can use this information to trigger rebuilds automatically when necessary. That looks nice, only two notes: - Looks like would be more sense on distinguish between SLOT and ABI_SLOT, for example: * dbus-glib would rdepend on glib:2 * if glib:2 abi changes, we would pull a ABI_SLOT=2.32 inside glib-2 ebuild * dbus-glib rdepending on glib:=2 would get rebuilt If we would use SLOT for all the cases, how would we handle it? I mean, glib slot would be bumped to 2.32 and dbus-glib ebuilds updated to rdepend on every new slot? Or would package managers distinct between versions inside the same SLOT variable? For this situation, it seems like it's easier to have separate SLOT and ABI_SLOT entities. Maybe the dbus-glib dependency would be expressed as glib:2:= and the package manager would translate that to glib:2:2.32 at build time. So, the atom has separate SLOT and ABI_SLOT parts. - What would occur with packages forced to use eapi0 due backwards compat? We could probably deprecate eapis older than 5 to allow all the tree be consistent with this rebuilds forcing, but no idea what to do with system packages still needing to use eapi0 and maybe changing their ABI too :/ All EAPIs have SLOT, so at least the reverse dependencies on these system packages would be able to use SLOT operator deps. It's also conceivable that ABI_SLOT support could be retroactively added to older EAPIs. Obviously, the SLOT operator := dependencies themselves can only be used in new EAPIs, so you won't be able to use them until you're willing to bump the EAPI of your package. -- Thanks, Zac
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On Wed, 06 Jun 2012 11:48:26 +0200 Pacho Ramos pa...@gentoo.org wrote: That looks nice, only two notes: - Looks like would be more sense on distinguish between SLOT and ABI_SLOT, for example: * dbus-glib would rdepend on glib:2 * if glib:2 abi changes, we would pull a ABI_SLOT=2.32 inside glib-2 ebuild * dbus-glib rdepending on glib:=2 would get rebuilt If we would use SLOT for all the cases, how would we handle it? I mean, glib slot would be bumped to 2.32 and dbus-glib ebuilds updated to rdepend on every new slot? Or would package managers distinct between versions inside the same SLOT variable? You'd have a slot per ABI, and be encouraged to allow multiple versions of glib to be installed in parallel. If you really couldn't do that (and you should think very carefully before saying you can't, since this directly affects users in a huge way), you can make the slots block each other. - What would occur with packages forced to use eapi0 due backwards compat? We could probably deprecate eapis older than 5 to allow all the tree be consistent with this rebuilds forcing, but no idea what to do with system packages still needing to use eapi0 and maybe changing their ABI too :/ The situation for older packages remains the same. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On Wed, 06 Jun 2012 10:32:08 +0200 Pacho Ramos pa...@gentoo.org wrote: We do? Please tell us. I was under the impression that we still didn't fully know what the problem was. Well, could you please let me know how to handle some issues already mentioned? For example: - Rebuild dbus-glib and gobject-introspection after major glib update. - Rebuild x11 drivers after xorg-update Those are the ones we probably do understand. You just up the SLOT (and if you really need to, use blockers between slots, although this is discouraged in favour of writing better ebuilds), and everything that build+run-deps upon these things uses := dependencies. - Rebuild python/perl/ocaml stuff after python/perl/ocaml update That depends. If you only have to do it after an upgrade, same solution. If you have to do it with a rebuild too, then that's one of the situations I claim we don't fully understand because no-one has specified what the exact general problem is (although lots of people have looked at one particular case and assumed that their case holds for everything, which isn't true). -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] About forcing rebuilds of other packages issue
El mié, 06-06-2012 a las 18:16 +0100, Ciaran McCreesh escribió: On Wed, 06 Jun 2012 11:48:26 +0200 Pacho Ramos pa...@gentoo.org wrote: That looks nice, only two notes: - Looks like would be more sense on distinguish between SLOT and ABI_SLOT, for example: * dbus-glib would rdepend on glib:2 * if glib:2 abi changes, we would pull a ABI_SLOT=2.32 inside glib-2 ebuild * dbus-glib rdepending on glib:=2 would get rebuilt If we would use SLOT for all the cases, how would we handle it? I mean, glib slot would be bumped to 2.32 and dbus-glib ebuilds updated to rdepend on every new slot? Or would package managers distinct between versions inside the same SLOT variable? You'd have a slot per ABI, and be encouraged to allow multiple versions of glib to be installed in parallel. If you really couldn't do that (and you should think very carefully before saying you can't, since this directly affects users in a huge way), you can make the slots block each other. Probably other gnome team could reply this better than me, but I don't think slotting every glib-2 due ABI changes deserves the huge effort. Also, we want people to rebuild them against, for example, glib-2.32 ABI, not to keep glib-2.30 and 2.32 installed in parallel and some packages built against 2.30 and others against 2.32. Also, how could this be handled in dbus-glib side? I mean, would we need to update dbus-glib update from RDEPENDing on glib:2.30 to glib:2.32? :O - What would occur with packages forced to use eapi0 due backwards compat? We could probably deprecate eapis older than 5 to allow all the tree be consistent with this rebuilds forcing, but no idea what to do with system packages still needing to use eapi0 and maybe changing their ABI too :/ The situation for older packages remains the same. Maybe we have a third option that could allow us to not use ABI_SLOT if you prefer: - eapi5 could allow the usage of depending on multiple slots, for example, dbus-glib would RDEPEND on dev-libs/glib:2.*:= Then, we would have dev-libs/glib:2.30 and dev-libs/glib:2.32, both mutually exclusive but ebuilds RDEPENDing on them not needing to be updated on every abi bump due them really working for both ABIs. - Package managers would still rebuild all apps with that := syntax - We would be able to skip ABI_SLOT needing - If a package is RDEPENDing on an old eapi0 package, that package could still use SLOT=2.32 or 2.30 and eapi5 ebuild rdepending on it still behaving in the same way. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About forcing rebuilds of other packages issue
El mié, 06-06-2012 a las 18:19 +0100, Ciaran McCreesh escribió: On Wed, 06 Jun 2012 10:32:08 +0200 Pacho Ramos pa...@gentoo.org wrote: We do? Please tell us. I was under the impression that we still didn't fully know what the problem was. Well, could you please let me know how to handle some issues already mentioned? For example: - Rebuild dbus-glib and gobject-introspection after major glib update. - Rebuild x11 drivers after xorg-update Those are the ones we probably do understand. You just up the SLOT (and if you really need to, use blockers between slots, although this is discouraged in favour of writing better ebuilds), and everything that build+run-deps upon these things uses := dependencies. - Rebuild python/perl/ocaml stuff after python/perl/ocaml update That depends. If you only have to do it after an upgrade, same solution. If you have to do it with a rebuild too, then that's one of the situations I claim we don't fully understand because no-one has specified what the exact general problem is (although lots of people have looked at one particular case and assumed that their case holds for everything, which isn't true). I think they are only needed on upgrades, not rebuilds, but I cannot assure that, probably their maintainers will know better :) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On Wed, 06 Jun 2012 20:02:24 +0200 Pacho Ramos pa...@gentoo.org wrote: Probably other gnome team could reply this better than me, but I don't think slotting every glib-2 due ABI changes deserves the huge effort. Think of the users. Also, we want people to rebuild them against, for example, glib-2.32 ABI, not to keep glib-2.30 and 2.32 installed in parallel and some packages built against 2.30 and others against 2.32. Well, you can do that if you really want... Also, how could this be handled in dbus-glib side? I mean, would we need to update dbus-glib update from RDEPENDing on glib:2.30 to glib:2.32? :O Noo. You'd use := dependencies, possibly with a = constraint. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] About forcing rebuilds of other packages issue
El mié, 06-06-2012 a las 19:15 +0100, Ciaran McCreesh escribió: On Wed, 06 Jun 2012 20:02:24 +0200 Pacho Ramos pa...@gentoo.org wrote: Probably other gnome team could reply this better than me, but I don't think slotting every glib-2 due ABI changes deserves the huge effort. Think of the users. I am thinking on them (well, I started this thread because I was thinking as a user). Also, we want people to rebuild them against, for example, glib-2.32 ABI, not to keep glib-2.30 and 2.32 installed in parallel and some packages built against 2.30 and others against 2.32. Well, you can do that if you really want... Also, how could this be handled in dbus-glib side? I mean, would we need to update dbus-glib update from RDEPENDing on glib:2.30 to glib:2.32? :O Noo. You'd use := dependencies, possibly with a = constraint. But, what would occur if we have three slots (for example gtk+), and app needs to RDEPEND on slot 2? How would we set it to use every 2.* SLOT and not =2? Also, what is the reason to try to skip ABI_SLOT way? It would have some advantages, and would allow us to make ABI_SLOTs mutually exclusive by default (as most cases would need) instead of needing to move this mutual exclussion on every ebuild needing to use SLOTs for ABI bumps. It looks cleaner to me over being constraint to SLOT :| signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On Wed, 06 Jun 2012 20:30:52 +0200 Pacho Ramos pa...@gentoo.org wrote: Also, how could this be handled in dbus-glib side? I mean, would we need to update dbus-glib update from RDEPENDing on glib:2.30 to glib:2.32? :O Noo. You'd use := dependencies, possibly with a = constraint. But, what would occur if we have three slots (for example gtk+), and app needs to RDEPEND on slot 2? How would we set it to use every 2.* SLOT and not =2? Then you'd need range dependencies. Also, what is the reason to try to skip ABI_SLOT way? No-one's ever implemented it, or knows how it works, or knows what exactly it's supposed to do. The only advantage ABI_SLOT has is that we don't know what its limitations are, other than that it doesn't solve any new problems (although it might slightly simplify certain specific cases, maybe). -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] About forcing rebuilds of other packages issue
El mié, 06-06-2012 a las 19:33 +0100, Ciaran McCreesh escribió: On Wed, 06 Jun 2012 20:30:52 +0200 Pacho Ramos pa...@gentoo.org wrote: Also, how could this be handled in dbus-glib side? I mean, would we need to update dbus-glib update from RDEPENDing on glib:2.30 to glib:2.32? :O Noo. You'd use := dependencies, possibly with a = constraint. But, what would occur if we have three slots (for example gtk+), and app needs to RDEPEND on slot 2? How would we set it to use every 2.* SLOT and not =2? Then you'd need range dependencies. Also, what is the reason to try to skip ABI_SLOT way? No-one's ever implemented it, or knows how it works, or knows what exactly it's supposed to do. The only advantage ABI_SLOT has is that we don't know what its limitations are, other than that it doesn't solve any new problems (although it might slightly simplify certain specific cases, maybe). Well, I think reading this thread is more or less clear what it would be supposed to do, also Zac suggested it and looks to have an idea about what should it do. In summary: we would still need to use a top layer SLOT for packages really being able to be parallel installed and those that need to be parallel installable because reverse dependencies doesn't work with latest version (like glib, libgda, gtk+...). ABI_SLOT would be more internal to allow portage managers to know that abi changed and reverse dependencies would need a later rebuild. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On Wed, 06 Jun 2012 21:16:05 +0200 Pacho Ramos pa...@gentoo.org wrote: Well, I think reading this thread is more or less clear what it would be supposed to do, also Zac suggested it and looks to have an idea about what should it do. There's a big leap from more or less clear and an idea to the kind of knowledge we want to have. Think REQUIRED_USE for how this can go wrong... If you think ABI_SLOT is essential, why not try implementing it and trying it out in a large number of packages, and reporting your results? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] About forcing rebuilds of other packages issue
El mié, 06-06-2012 a las 20:23 +0100, Ciaran McCreesh escribió: On Wed, 06 Jun 2012 21:16:05 +0200 Pacho Ramos pa...@gentoo.org wrote: Well, I think reading this thread is more or less clear what it would be supposed to do, also Zac suggested it and looks to have an idea about what should it do. There's a big leap from more or less clear and an idea to the kind of knowledge we want to have. Think REQUIRED_USE for how this can go wrong... If you think ABI_SLOT is essential, why not try implementing it and trying it out in a large number of packages, and reporting your results? Because I don't have the skills to do it myself signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On 06/06/2012 10:16 AM, Ciaran McCreesh wrote: On Wed, 06 Jun 2012 11:48:26 +0200 Pacho Ramos pa...@gentoo.org wrote: That looks nice, only two notes: - Looks like would be more sense on distinguish between SLOT and ABI_SLOT, for example: * dbus-glib would rdepend on glib:2 * if glib:2 abi changes, we would pull a ABI_SLOT=2.32 inside glib-2 ebuild * dbus-glib rdepending on glib:=2 would get rebuilt If we would use SLOT for all the cases, how would we handle it? I mean, glib slot would be bumped to 2.32 and dbus-glib ebuilds updated to rdepend on every new slot? Or would package managers distinct between versions inside the same SLOT variable? You'd have a slot per ABI, and be encouraged to allow multiple versions of glib to be installed in parallel. If you really couldn't do that (and you should think very carefully before saying you can't, since this directly affects users in a huge way), you can make the slots block each other. It seems like you're trying to make glib fit your SLOT operator model, even though it's a natural fit for the ABI_SLOT operator model. -- Thanks, Zac
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On 06/06/2012 10:19 AM, Ciaran McCreesh wrote: On Wed, 06 Jun 2012 10:32:08 +0200 Pacho Ramos pa...@gentoo.org wrote: We do? Please tell us. I was under the impression that we still didn't fully know what the problem was. Well, could you please let me know how to handle some issues already mentioned? For example: - Rebuild dbus-glib and gobject-introspection after major glib update. - Rebuild x11 drivers after xorg-update Those are the ones we probably do understand. You just up the SLOT (and if you really need to, use blockers between slots, although this is discouraged in favour of writing better ebuilds), and everything that build+run-deps upon these things uses := dependencies. Can you explain how Exherbo is handling dbus-glib rebuilds after glib:2 updates? It seems that dbus-glib is not using a SLOT operator for its glib:2 dependency: http://git.exherbo.org/summer/packages/dev-libs/dbus-glib/index.html -- Thanks, Zac
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On 06/06/2012 12:23 PM, Ciaran McCreesh wrote: On Wed, 06 Jun 2012 21:16:05 +0200 Pacho Ramos pa...@gentoo.org wrote: Well, I think reading this thread is more or less clear what it would be supposed to do, also Zac suggested it and looks to have an idea about what should it do. There's a big leap from more or less clear and an idea to the kind of knowledge we want to have. Think REQUIRED_USE for how this can go wrong... If you think ABI_SLOT is essential, why not try implementing it and trying it out in a large number of packages, and reporting your results? It's pretty close to the SLOT operator model, and it seems like it should work fine. We can deploy EAPI 5_pre1 with ABI_SLOT support, and test it in an overlay before we include it in the final EAPI 5. -- Thanks, Zac
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On Wed, 06 Jun 2012 14:21:40 -0700 Zac Medico zmed...@gentoo.org wrote: You'd have a slot per ABI, and be encouraged to allow multiple versions of glib to be installed in parallel. If you really couldn't do that (and you should think very carefully before saying you can't, since this directly affects users in a huge way), you can make the slots block each other. It seems like you're trying to make glib fit your SLOT operator model, even though it's a natural fit for the ABI_SLOT operator model. No, I'm trying to strongly encourage people to make proper use of slots to avoid having mass breakages and annoyances on user systems, even if it means more work for developers. Broken linkage due to an upgrade really shouldn't happen. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] About forcing rebuilds of other packages issue
El mar, 05-06-2012 a las 08:44 -0400, Aaron W. Swenson escribió: [...] There's never anything important in all that text. - Anonymous Gentoo User We've already determined that the users don't read the output. This is a known fact. Something I repeat in #gentoo more often than I care to admit is Seriously, read the output. I agree with the users that there's too much output, and some of the output is indeed useless. The output they aren't reading isn't just rebuild commands, but also the next step they're supposed to take after the emerge has finished, groups their users need to be in to use a particular feature, et cetera. The ideal solution is for the Ebuild to instruct the PMS to rebuild the dependent packages. We can have a variable called REBUILD. All packages that would need to be rebuilt can be listed in it. Only those packages that are installed would be built. The actual list of the packages to be rebuilt would be determined at dependency checking time. That way, the user can approve the rebuild of the packages. We all know what would be the ideal solution, the problem is how to implement it (and how many years we need to wait to get it working). Just placing the commands in a separate log won't really solve a whole lot. Further, it will bump any elog messages even further down in the importance ranking. It will allow administrators to easily automate via scripts rebuilding of packages, allowing them to get system more solid after a big update. Also, currently I usually need to surf in big summary.log to directly find commands to rebuild things because most of elog messages are useless to me (a lot of them because they are always shown in every update and are useful only the first time you read them, other times you already remember, for example, how to setup e4rat). Current situation of breaking systems when people don't read summary.log JUST AFTER update completes won't help to force people to read them, will simply break their systems and give a really poor impression of Gentoo breaking easily when updating. Think, for example, on a lot of people that leaves system updating at night time, then, when he/she tries to use it next morning he sees some things are broken and need to be rebuilt. All that rebuilding work could be done during the same night but, due current way of handling things, he needs to have his system broken during more hours (when he needs to use it) until things are rebuilt. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On 06/05/2012 06:31 AM, Pacho Ramos wrote: El mar, 05-06-2012 a las 08:44 -0400, Aaron W. Swenson escribió: The ideal solution is for the Ebuild to instruct the PMS to rebuild the dependent packages. We can have a variable called REBUILD. All packages that would need to be rebuilt can be listed in it. Only those packages that are installed would be built. The actual list of the packages to be rebuilt would be determined at dependency checking time. That way, the user can approve the rebuild of the packages. We all know what would be the ideal solution, the problem is how to implement it (and how many years we need to wait to get it working). This REBUILD variable is the first idea that pops into the head of anyone who's never worked on a dependency resolver before. It's backwards because it requires a package to have knowledge of *all* of its reverse dependencies, and it should not need to know about *any* of them. The SLOT operator dependencies that Ciaran has been advocating are very close to a good solution. However, if we want it to work with unslotted packages, then we need to introduce a separate ABI_SLOT variable as discussed here: https://bugs.gentoo.org/show_bug.cgi?id=192319#c18 It's really no more difficult to do than SLOT operator dependencies, it's more flexible, and we can do it in EAPI 5. -- Thanks, Zac
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On Tue, 05 Jun 2012 16:07:40 -0700 Zac Medico zmed...@gentoo.org wrote: The SLOT operator dependencies that Ciaran has been advocating are very close to a good solution. However, if we want it to work with unslotted packages, then we need to introduce a separate ABI_SLOT variable as discussed here: https://bugs.gentoo.org/show_bug.cgi?id=192319#c18 It's really no more difficult to do than SLOT operator dependencies, it's more flexible, and we can do it in EAPI 5. I still don't get what problem you're trying to solve with that. SLOT operator dependencies are known to work for the problem, and have received extensive testing both on Gentoo (with the old KDE packages) and elsewhere. Why not just go with those plus blockers initially, and then add in ABI_SLOT only if it turns out that developers really can't handle using SLOT correctly? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On Tue, 05 Jun 2012 15:31:01 +0200 Pacho Ramos pa...@gentoo.org wrote: We all know what would be the ideal solution, the problem is how to implement it (and how many years we need to wait to get it working). We do? Please tell us. I was under the impression that we still didn't fully know what the problem was. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On 06/05/2012 10:31 PM, Ciaran McCreesh wrote: On Tue, 05 Jun 2012 16:07:40 -0700 Zac Medico zmed...@gentoo.org wrote: The SLOT operator dependencies that Ciaran has been advocating are very close to a good solution. However, if we want it to work with unslotted packages, then we need to introduce a separate ABI_SLOT variable as discussed here: https://bugs.gentoo.org/show_bug.cgi?id=192319#c18 It's really no more difficult to do than SLOT operator dependencies, it's more flexible, and we can do it in EAPI 5. I still don't get what problem you're trying to solve with that. Well, I guess it's easy enough to use blockers to handle cases where two SLOTs can't be installed simultaneously. SLOT operator dependencies are known to work for the problem, and have received extensive testing both on Gentoo (with the old KDE packages) and elsewhere. Why not just go with those plus blockers initially, and then add in ABI_SLOT only if it turns out that developers really can't handle using SLOT correctly? Sounds good, especially considering the possibility of using blockers as mentioned. -- Thanks, Zac
[gentoo-dev] About forcing rebuilds of other packages issue
Hello, will send this to gentoo-dev mailing list per Zac's suggestion ;): Probably Zac already remembers my suggestion of: https://bugs.gentoo.org/show_bug.cgi?id=413619 Sorry for insisting a bit on it but this issue bites me periodically. Months ago, I was able to administrate myself some of my father and uncles systems in their jobs and homes but, since I moved to Madrid this year, I am not able to administrate them directly. They usually do a good job maintaining them, the only issue I see they hit from time to time is forgetting to run JUST AFTER updating their systems revdep-rebuild (well, this is so common that they usually don't forget to), rebuild dbus-glib/gobject-introspection after major glib update, rebuild X11 drivers... This is because, even if all this information is recorded in /var/log/portage/elog/summary.log, currently, that log file is cluttered of a lot of other elog lines that are not related at all with this important task of rebuilding packages. This is why I suggested: https://bugs.gentoo.org/show_bug.cgi?id=413619 That would create a new erebuild (or whatever the name you prefer) to ONLY contain exact command to run by admin to have a safe system after update. It would have as main advantage: - Looks easier to implement. - It relies in current and existing tools (python-updater, perl-cleaner, q, equery...), then, they could be used just now via a script running all of them. - It also looks much more professional to try to unify a bit what commands to run ;) (currently, some ebuilds tells you to manually re-emerge packages and some people wrongly run emerge dbus-glib when they should run emerge -1 dbus-glib. Telling us to people what exact command they need to copypasterun will help to get their systems cleaner also. Zac kindly pointed me to: https://bugs.gentoo.org/show_bug.cgi?id=192319 The problem of that one is that, even if it would be the perfect solution: - Looks to be stalled for a long time. - Looks to need a lot of functions (like revdep-rebuild, python-updater...) to be merged in portage itself. It will then probably take a lot of time to get them integrated (specially seeing we are still not able to use preserve-libs because it looks to cause some other problems) - In that bug report I have also seen discussion about whether handle this only via SLOTs (that personally think it will be even harder to achieve for all packages in the tree showing this kind of problems when updating, for example, I doubt how glib - dbus-glib/g-i case could be handled in this way. - Looks like there is no consensus about what to do and, then, this could probably be implemented on eapi... 7? While former could probably be implemented much sooner (probably even in eapi5) This is why I think we should try to push a bit my first suggestion for the short term until the perfect one is ready as, until then, we are having for years a problem that, personally, I think it should be handled a bit better. Thanks a lot for your attention signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On 06/04/2012 02:29 PM, Pacho Ramos wrote: - Looks like there is no consensus about what to do and, then, this could probably be implemented on eapi... 7? While former could probably be implemented much sooner (probably even in eapi5) Ciaran has been advocating SLOT operator dependencies for this, but those are not designed to work with unslotted packages, which leads to the issues discussed in bug 414955: https://bugs.gentoo.org/show_bug.cgi?id=414955#c10 -- Thanks, Zac
