[gentoo-dev] [gentoo-portage-dev] About forcing rebuilds of other packages issue

[gentoo-dev] [gentoo-portage-dev] About forcing rebuilds of other packages issue

[Pacho Ramos]

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

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 copy&paste&run 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


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

Re: [gentoo-dev] [gentoo-portage-dev] About forcing rebuilds of other packages issue

[Aaron W. Swenson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 06/04/2012 05:26 PM, Pacho Ramos wrote:
> Hello, will send this to gentoo-dev mailing list per Zac's
> suggestion ;):
> 
> ...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 copy&paste&run will help to get their systems 
> cleaner also.
> 
> ...
> 
> 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
> 

"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.

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.

- --
Mr. Aaron W. Swenson
Gentoo Linux Developer
Email    : titanofold@gentoo.org
GnuPG FP : 2C00 7719 4F85 FB07 A49C  0E31 5713 AA03 D1BB FDA0
GnuPG ID : D1BBFDA0
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAk/N/xgACgkQVxOqA9G7/aBGGwD/TNRbZNie6J1RkI0DETgcUlwG
VXBY2UamMijjKLFPluEA/jwo9B7qejNkiko/xDvecUq8CaF02Qc4tKMf/MbWs7LW
=ysgF
-----END PGP SIGNATURE-----

Re: [gentoo-dev] About forcing rebuilds of other packages issue

[Pacho Ramos]

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

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.


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

Re: [gentoo-dev] About forcing rebuilds of other packages issue

[Zac Medico]

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

[Ciaran McCreesh]

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

On Tue, 05 Jun 2012 16:07:40 -0700
Zac Medico <zmedico@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

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

Re: [gentoo-dev] About forcing rebuilds of other packages issue

[Zac Medico]

On 06/05/2012 10:31 PM, Ciaran McCreesh wrote:
> On Tue, 05 Jun 2012 16:07:40 -0700
> Zac Medico <zmedico@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

Re: [gentoo-dev] About forcing rebuilds of other packages issue

[Pacho Ramos]

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

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

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

Re: [gentoo-dev] About forcing rebuilds of other packages issue

[Zac Medico]

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

[Pacho Ramos]

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

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 :/


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

Re: [gentoo-dev] About forcing rebuilds of other packages issue

[Zac Medico]

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

[Ciaran McCreesh]

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

On Wed, 06 Jun 2012 11:48:26 +0200
Pacho Ramos <pacho@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

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

Re: [gentoo-dev] About forcing rebuilds of other packages issue

[Pacho Ramos]

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

El mié, 06-06-2012 a las 18:16 +0100, Ciaran McCreesh escribió:
> On Wed, 06 Jun 2012 11:48:26 +0200
> Pacho Ramos <pacho@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.



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

Re: [gentoo-dev] About forcing rebuilds of other packages issue

[Ciaran McCreesh]

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

On Wed, 06 Jun 2012 20:02:24 +0200
Pacho Ramos <pacho@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

Noooooo. You'd use := dependencies, possibly with a >= constraint.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] About forcing rebuilds of other packages issue

[Pacho Ramos]

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

El mié, 06-06-2012 a las 19:15 +0100, Ciaran McCreesh escribió:
> On Wed, 06 Jun 2012 20:02:24 +0200
> Pacho Ramos <pacho@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
> 
> Noooooo. 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 :|

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

Re: [gentoo-dev] About forcing rebuilds of other packages issue

[Ciaran McCreesh]

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

On Wed, 06 Jun 2012 20:30:52 +0200
Pacho Ramos <pacho@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
> > 
> > Noooooo. 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

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

Re: [gentoo-dev] About forcing rebuilds of other packages issue

[Pacho Ramos]

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

El mié, 06-06-2012 a las 19:33 +0100, Ciaran McCreesh escribió:
> On Wed, 06 Jun 2012 20:30:52 +0200
> Pacho Ramos <pacho@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
> > > 
> > > Noooooo. 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.

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

Re: [gentoo-dev] About forcing rebuilds of other packages issue

[Ciaran McCreesh]

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

On Wed, 06 Jun 2012 21:16:05 +0200
Pacho Ramos <pacho@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

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

Re: [gentoo-dev] About forcing rebuilds of other packages issue

[Pacho Ramos]

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

El mié, 06-06-2012 a las 20:23 +0100, Ciaran McCreesh escribió:
> On Wed, 06 Jun 2012 21:16:05 +0200
> Pacho Ramos <pacho@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

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

Re: [gentoo-dev] About forcing rebuilds of other packages issue

[Zac Medico]

On 06/06/2012 12:23 PM, Ciaran McCreesh wrote:
> On Wed, 06 Jun 2012 21:16:05 +0200
> Pacho Ramos <pacho@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

[Brian Harring]

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 <pacho@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

[Zac Medico]

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 <pacho@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

[Ciaran McCreesh]

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

On Thu, 07 Jun 2012 09:43:32 -0700
Zac Medico <zmedico@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

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

Re: [gentoo-dev] About forcing rebuilds of other packages issue

[Pacho Ramos]

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

El jue, 07-06-2012 a las 18:40 +0100, Ciaran McCreesh escribió:
> On Thu, 07 Jun 2012 09:43:32 -0700
> Zac Medico <zmedico@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.



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

Re: [gentoo-dev] About forcing rebuilds of other packages issue

[Zac Medico]

On 06/07/2012 10:40 AM, Ciaran McCreesh wrote:
> On Thu, 07 Jun 2012 09:43:32 -0700
> Zac Medico <zmedico@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

[Ciaran McCreesh]

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

On Thu, 07 Jun 2012 11:03:25 -0700
Zac Medico <zmedico@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

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

Re: [gentoo-dev] About forcing rebuilds of other packages issue

[Pacho Ramos]

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

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 <zmedico@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

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

Re: [gentoo-dev] About forcing rebuilds of other packages issue

[Pacho Ramos]

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

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 <zmedico@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?

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

Re: [gentoo-dev] About forcing rebuilds of other packages issue

[Ciaran McCreesh]

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

On Thu, 07 Jun 2012 20:43:54 +0200
Pacho Ramos <pacho@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

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

Re: [gentoo-dev] About forcing rebuilds of other packages issue

[Pacho Ramos]

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

El jue, 07-06-2012 a las 19:44 +0100, Ciaran McCreesh escribió:
> On Thu, 07 Jun 2012 20:43:54 +0200
> Pacho Ramos <pacho@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...)

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

Re: [gentoo-dev] About forcing rebuilds of other packages issue

[Zac Medico]

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 <pacho@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

[Pacho Ramos]

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

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

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

Re: [gentoo-dev] About forcing rebuilds of other packages issue

[Zac Medico]

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 <pacho@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

[Pacho Ramos]

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

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 <pacho@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 :|

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

Re: [gentoo-dev] About forcing rebuilds of other packages issue

[Zac Medico]

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 <pacho@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

[Pacho Ramos]

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

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 <pacho@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 :|

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

Re: [gentoo-dev] About forcing rebuilds of other packages issue

[Ian Stakenvicius]

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

[Zac Medico]

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 <pacho@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

[Pacho Ramos]

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

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 <pacho@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

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

Re: [gentoo-dev] About forcing rebuilds of other packages issue

[Pacho Ramos]

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

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

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

Re: [gentoo-dev] About forcing rebuilds of other packages issue

[Ciaran McCreesh]

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

On Fri, 08 Jun 2012 12:31:55 -0700
Zac Medico <zmedico@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

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

Re: [gentoo-dev] About forcing rebuilds of other packages issue

[Zac Medico]

On 06/09/2012 05:15 AM, Ciaran McCreesh wrote:
> On Fri, 08 Jun 2012 12:31:55 -0700
> Zac Medico <zmedico@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

[Ciaran McCreesh]

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

On Sat, 09 Jun 2012 13:55:53 -0700
Zac Medico <zmedico@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

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

Re: [gentoo-dev] About forcing rebuilds of other packages issue

[Davide Pesavento]

On Sun, Jun 10, 2012 at 2:25 PM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Sat, 09 Jun 2012 13:55:53 -0700
> Zac Medico <zmedico@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

[Ian Stakenvicius]

-----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.mccreesh@googlemail.com> wrote:
>> On Sat, 09 Jun 2012 13:55:53 -0700 Zac Medico
>> <zmedico@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

[Zac Medico]

On 06/10/2012 05:25 AM, Ciaran McCreesh wrote:
> On Sat, 09 Jun 2012 13:55:53 -0700
> Zac Medico <zmedico@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

[Zac Medico]

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 <zmedico@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

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

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
>>> <zmedico@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.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk/oYYcACgkQ2ugaI38ACPBZ3QEAkXXOmiTdC/7Hgl84c2oSlwbM
5YNUbcgh6wI59FTCAboA/RGdo1YptVCvmHYlyvJ2VKNY98pq2g+FKhY1T7SAbrlo
=hXfd
-----END PGP SIGNATURE-----

Re: [gentoo-dev] About forcing rebuilds of other packages issue

[Zac Medico]

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
>>>> <zmedico@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

[Ian Stakenvicius]

-----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 
>>>>> <zmedico@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-----

[gentoo-dev] About forcing rebuilds of perl modules

[Torsten Veller]

* Ian Stakenvicius <axs@gentoo.org>:
> 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.

Perl modules have to be rebuilt if dev-lang/perl's useflags are changed.

That would make dev-lang/perl's SLOT depend on users USE flags settings which
is forbidden. Or will it work for sub-slot part?
SLOT="0/5.16(?ithreads:-ithreads)(?debug:-debug)"

-- 
Thanks
Torsten

Re: [gentoo-dev] About forcing rebuilds of perl modules

[Zac Medico]

On 06/30/2012 01:46 AM, Torsten Veller wrote:
> * Ian Stakenvicius <axs@gentoo.org>:
>> 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.
> 
> Perl modules have to be rebuilt if dev-lang/perl's useflags are changed.
> 
> That would make dev-lang/perl's SLOT depend on users USE flags settings which
> is forbidden. Or will it work for sub-slot part?
> SLOT="0/5.16(?ithreads:-ithreads)(?debug:-debug)"

Maybe this useflags synchronization thing is best managed with the
existing USE deps support? So, if something interacts with perls
ithreads and debug flags, its dependency should be something like
dev-lang/perl[ithreads=][debug=].
-- 
Thanks,
Zac

Re: [gentoo-dev] About forcing rebuilds of perl modules

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 30/06/12 05:30 AM, Zac Medico wrote:
> On 06/30/2012 01:46 AM, Torsten Veller wrote:
>> * Ian Stakenvicius <axs@gentoo.org>:
>>> 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.
>> 
>> Perl modules have to be rebuilt if dev-lang/perl's useflags are 
>> changed.
>> 
>> That would make dev-lang/perl's SLOT depend on users USE flags 
>> settings which is forbidden. Or will it work for sub-slot part? 
>> SLOT="0/5.16(?ithreads:-ithreads)(?debug:-debug)"
> 
> Maybe this useflags synchronization thing is best managed with the
>  existing USE deps support? So, if something interacts with perls 
> ithreads and debug flags, its dependency should be something like 
> dev-lang/perl[ithreads=][debug=].

I think this makes a lot of sense too -- use-flag synchronization
would probably be best handled outside of SLOT, otherwise we'd have to
implement dynamic slots to get this properly supported.

Now, that being said, it might be worthwhile if perl-module was
expanded a bit in relation to the *DEPEND it adds -- having a
PERL_MODULE_USES var or something, that could automatically append to
IUSE (if necessary) and set the use-deps on dev-lang/perl, would make
this a fairly simple implementation I think.

Do all packages need to be rebuilt when some of these use flags
change?  Maybe auto-appending those particular flags (ithreads, debug)
to IUSE and putting them on the dev-lang/perl dep is all that'll be
needed, if this is the case.

- -----

On an semi-related note, I have noticed that there are a fair number
of ebuilds in the tree that are using perl-module at EAPI=4 and have
'perl? (dev-lang/perl)' in *DEPEND, but are not setting
GENTOO_DEPEND_ON_PERL=no before their inherit (and so perl is ALWAYS a
dep).  I'm thinking of filing bugs against all of these...

- -----

Finally, thanks for testing!!  I hope to improve the overlay a bit by
the middle of next week, including a script that'll patch /var/db/pkg
to simulate 4-slot-abi always existing (so one doesn't have to emerge
- -e @world to get their environment ready to test).

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAk/vM28ACgkQ2ugaI38ACPAXlAD+KvzYGYMaTbgYS3eT6ADGzhEv
4+ehZ4PQ+9fNEyBMpn8A/2GXQqWY9erx+Dd8FL/jwk8KbReJoMwfffPEWCe38rfW
=4DDP
-----END PGP SIGNATURE-----

Re: [gentoo-dev] About forcing rebuilds of perl modules

[Kent Fredric]

On 1 July 2012 05:12, Ian Stakenvicius <axs@gentoo.org> wrote:
> Do all packages need to be rebuilt when some of these use flags
> change?  Maybe auto-appending those particular flags (ithreads, debug)
> to IUSE and putting them on the dev-lang/perl dep is all that'll be
> needed, if this is the case.


Not all packages need rebuilding, but *every* package with XS parts
need rebuilding, as code built with DEBUG/ITHREADS enabled will not
execute on perls with different DEBUG/ITHREADS options. ( And as a
preventative measure, they're installed in entirely different dirs )

 @INC:
    /etc/perl
    /usr/local/lib64/perl5/5.16.0/x86_64-linux   <- binary
    /usr/local/lib64/perl5/5.16.0
    /usr/lib64/perl5/vendor_perl/5.16.0/x86_64-linux  <-- binary
    /usr/lib64/perl5/vendor_perl/5.16.0
    /usr/lib64/perl5/5.16.0/x86_64-linux <-- binary
    /usr/lib64/perl5/5.16.0
    .

    .

( At least, the dir name switching used to be a thing, I can't see it
in the code anymore so I could be wrong, I don't tend to twiddle those
USE flags often )

Also, it would appear that in some cases ( ie: dev-perl/Mouse ) , they
don't install any binary code , but the .pm files themselves are
installed into the x86_64-linux folder, which, if that path is removed
from @INC when you rebuild perl with different USE flags, will break
them, despite not having any binary code.

But either way, if "SlotABI" is supposed to convey "A change that can
occur to a package that means other packages that were built on it
need to be rebuilt" , then this is something we need.

-- 
Kent

perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] About forcing rebuilds of perl modules

[Zac Medico]

On 07/06/2012 06:17 PM, Kent Fredric wrote:
> But either way, if "SlotABI" is supposed to convey "A change that can
> occur to a package that means other packages that were built on it
> need to be rebuilt" , then this is something we need.

Much like SLOT, SLOT/ABI-sub-slot as it's implemented in EAPI 4-slot-abi
[1] is intended to correlate to some extent with the package version.

Rebuilds involving USE changes have already been supported since EAPI 2
via USE deps. With existing versions of portage, you have to run
something like `emerge --newuse -uD @world` to ensure that everything is
rebuilt to match current USE settings. However, it would be fairly easy
to make emerge more pro-active about triggering rebuilds to satisfy
reverse USE dependencies when necessary.

[1]
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

[Pacho Ramos]

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

El dom, 10-06-2012 a las 13:25 +0100, Ciaran McCreesh escribió:
> On Sat, 09 Jun 2012 13:55:53 -0700
> Zac Medico <zmedico@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 :)

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

Re: [gentoo-dev] About forcing rebuilds of other packages issue

[Brian Harring]

On Sun, Jun 10, 2012 at 01:25:55PM +0100, Ciaran McCreesh wrote:
> On Sat, 09 Jun 2012 13:55:53 -0700
> Zac Medico <zmedico@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

[Ian Stakenvicius]

-----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
>> <zmedico@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

[Ian Stakenvicius]

-----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 <pacho@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

[Ciaran McCreesh]

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

On Thu, 07 Jun 2012 15:14:03 -0400
Ian Stakenvicius <axs@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

[Brian Harring]

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 <axs@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

[Ralph Sennhauser]

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

On Thu, 07 Jun 2012 09:43:32 -0700
Zac Medico <zmedico@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 <pacho@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.

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

Re: [gentoo-dev] About forcing rebuilds of other packages issue

[Zac Medico]

On 06/07/2012 11:04 AM, Ralph Sennhauser wrote:
> On Thu, 07 Jun 2012 09:43:32 -0700
> Zac Medico <zmedico@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 <pacho@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

[Zac Medico]

On 06/07/2012 11:04 AM, Ralph Sennhauser wrote:
> On Thu, 07 Jun 2012 09:43:32 -0700
> Zac Medico <zmedico@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

[Zac Medico]

On 06/06/2012 10:16 AM, Ciaran McCreesh wrote:
> On Wed, 06 Jun 2012 11:48:26 +0200
> Pacho Ramos <pacho@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

[Ciaran McCreesh]

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

On Wed, 06 Jun 2012 14:21:40 -0700
Zac Medico <zmedico@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

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

Re: [gentoo-dev] About forcing rebuilds of other packages issue

[Zac Medico]

On 06/06/2012 10:28 PM, Ciaran McCreesh wrote:
> On Wed, 06 Jun 2012 14:21:40 -0700
> Zac Medico <zmedico@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

[Pacho Ramos]

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

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 <zmedico@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.


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

Re: [gentoo-dev] About forcing rebuilds of other packages issue

[Ciaran McCreesh]

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

On Thu, 07 Jun 2012 10:42:29 -0700
Zac Medico <zmedico@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

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

Re: [gentoo-dev] About forcing rebuilds of other packages issue

[Ciaran McCreesh]

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

On Tue, 05 Jun 2012 15:31:01 +0200
Pacho Ramos <pacho@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

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

Re: [gentoo-dev] About forcing rebuilds of other packages issue

[Pacho Ramos]

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

El mié, 06-06-2012 a las 06:33 +0100, Ciaran McCreesh escribió:
> On Tue, 05 Jun 2012 15:31:01 +0200
> Pacho Ramos <pacho@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 :)

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

Re: [gentoo-dev] About forcing rebuilds of other packages issue

[Ciaran McCreesh]

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

On Wed, 06 Jun 2012 10:32:08 +0200
Pacho Ramos <pacho@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

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

Re: [gentoo-dev] About forcing rebuilds of other packages issue

[Pacho Ramos]

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

El mié, 06-06-2012 a las 18:19 +0100, Ciaran McCreesh escribió:
> On Wed, 06 Jun 2012 10:32:08 +0200
> Pacho Ramos <pacho@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 :)

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

Re: [gentoo-dev] About forcing rebuilds of other packages issue

[Zac Medico]

On 06/06/2012 10:19 AM, Ciaran McCreesh wrote:
> On Wed, 06 Jun 2012 10:32:08 +0200
> Pacho Ramos <pacho@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

[Ciaran McCreesh]

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

On Wed, 06 Jun 2012 14:45:55 -0700
Zac Medico <zmedico@gentoo.org> wrote:
> Can you explain how Exherbo is handling dbus-glib rebuilds after
> glib:2 updates?

Badly, most likely.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] About forcing rebuilds of other packages issue

[Zac Medico]

On 06/06/2012 11:12 PM, Ciaran McCreesh wrote:
> On Wed, 06 Jun 2012 14:45:55 -0700
> Zac Medico <zmedico@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

[Wulf C. Krueger]

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

[Pacho Ramos]

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

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

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

Re: [gentoo-dev] About forcing rebuilds of other packages issue

[Ciaran McCreesh]

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

On Thu, 07 Jun 2012 10:47:19 -0700
Zac Medico <zmedico@gentoo.org> wrote:
> On 06/06/2012 11:12 PM, Ciaran McCreesh wrote:
> > On Wed, 06 Jun 2012 14:45:55 -0700
> > Zac Medico <zmedico@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

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

Re: [gentoo-dev] About forcing rebuilds of other packages issue

[Zac Medico]

On 06/07/2012 11:13 AM, Ciaran McCreesh wrote:
> On Thu, 07 Jun 2012 10:47:19 -0700
> Zac Medico <zmedico@gentoo.org> wrote:
>> On 06/06/2012 11:12 PM, Ciaran McCreesh wrote:
>>> On Wed, 06 Jun 2012 14:45:55 -0700
>>> Zac Medico <zmedico@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] [gentoo-portage-dev] About forcing rebuilds of other packages issue

[Ciaran McCreesh]

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

On Tue, 05 Jun 2012 08:44:08 -0400
"Aaron W. Swenson" <titanofold@gentoo.org> wrote:
> "There's never anything important in all that text." - Anonymous
> Gentoo User

To be fair, most einfo and elog messages are useless spam. When elog
was introduced, it was supposed to be only for *important* messages,
but nearly everything sent to it now is a waste of users' time.

Perhaps the solution is to implement an ethisisimportanthonestlog
function, and require developers to get approval before using it, as
per news items.

- -- 
Ciaran McCreesh
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iEYEARECAAYFAk/Oa+MACgkQ96zL6DUtXhHDhwCgpf1C/k//ecx21gcsCiCy6MK1
GRwAoNhvMaJSFxAbTdOGcqMcYhI5JuXN
=SNPn
-----END PGP SIGNATURE-----

Re: [gentoo-dev] [gentoo-portage-dev] About forcing rebuilds of other packages issue

[Michael Weber]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 06/05/2012 02:44 PM, Aaron W. Swenson wrote:

> "There's never anything important in all that text." - Anonymous 
> Gentoo User

The bad part is, that even reading of these messages can result in a
breakage. I update a bunch of machines with these steps (maybe we
should place instructions like these on a prominent place).
(this is multi user, multi session).

#preparations
eix-sync
cd /etc/portage
git pull ; [ git stash ; git pull ; git stash pop ; git commit -a ;
git push ]

#on kernel updates
emerge -av1 --nodeps gentoo-sources
cd /usr/src/linux ; zcat /proc/config.gz > .config
make oldconfig
time ( make -j8 && make install_modules && make install &&
	module-rebuild -X rebuild &&
	eclean-kernel -n 2 -x config &&
	grub2-config -o /boot/grub2/grub2.cfg )

#regular packages
emerge -avuND world
dispatch-conf/etc-update
emerge -a --depclean
revdep-rebuild --ignore -- -av
revdep-rebuild --ignore -- -av (second run)

#on xorg-server updates
emerge -av1 $(qlist -IC x11-drivers)

Nice, isn't it?

[1] if you forget the -X on module-rebuild, you might no longer have
the virtualbox-modules version installed in the tree (no packages
satisfy ...). virtualbox does remove old versions real quick.

The fun part comes with non-root users trying to log in:

[2] You've updated nvidia-drivers (kernel module providers in general)
userland and kernel modules, but forget to `rmmod nvidia`, or you
can't without terminating user sessions, it impossible to start new X
servers due to version mismatch between userland and kernel (applies
for virtualbox as well)

[3] You've updated zlib, but failed to recognize it in the emerge -av
output. You get angry reports about broken luatex and inkscape
(imagemagik) because of some nasty zlib abi version mismatch, hidden
from revdep-rebuild.

[5] lafilefixer (funny)
[4] python-updater (rare)
[6] ocaml gets broken after update w/o lablgl rebuild
  https://bugs.gentoo.org/385869

Well, I'm lazy, and do this in the backgound, half asleep.
And I admit that [1] and [2] are my faults, but [3] is very annoying
(just like libdl related stuff) and esp. kernel+module updates take a
lot more than just a few 'REBUILD' packages.

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 understand the urge for `eupdate` but that needs an agreement on
the implementation, and I see some rought edges here, where unattended
script magic most likely fails.

Michael -- half asleep

- --
Gentoo Dev
http://xmw.de/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF0EAREIAAYFAk/OqZ4ACgkQknrdDGLu8JCZTgD2MXNld64l2D9jdko5sDQ1RedO
hDDGT1frS210sIkG5AD+M0N08Ru0FrVmqarkxec6N71egAmrmRUmcMMhtWCcUK0=
=0Xwl
-----END PGP SIGNATURE-----

Re: [gentoo-dev] [gentoo-portage-dev] About forcing rebuilds of other packages issue

[Zac Medico]

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
-- 
Thanks,
Zac

Re: [gentoo-dev] [gentoo-portage-dev] About forcing rebuilds of other packages issue

[Pacho Ramos]

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

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?

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

Re: [gentoo-dev] [gentoo-portage-dev] About forcing rebuilds of other packages issue

[Zac Medico]

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

Re: [gentoo-dev] About forcing rebuilds of other packages issue

[Pacho Ramos]

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

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.

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

Re: [gentoo-dev] About forcing rebuilds of other packages issue

[Zac Medico]

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

[Peter Stuge]

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

[Ian Stakenvicius]

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

[Peter Stuge]

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

[Zac Medico]

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] [gentoo-portage-dev] About forcing rebuilds of other packages issue

[Brian Harring]

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

Re: [gentoo-dev] [gentoo-portage-dev] About forcing rebuilds of other packages issue

[Zac Medico]

On 06/06/2012 02:59 PM, Brian Harring wrote:
> 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. 

Yeah, I'm sure we can all agree that we would like the dependency
resolver to be able to predict/display all of the rebuilds that will
need to occur, before any building starts.
-- 
Thanks,
Zac

Re: [gentoo-dev] About forcing rebuilds of other packages issue

[Pacho Ramos]

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

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)

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

Re: [gentoo-dev] [gentoo-portage-dev] About forcing rebuilds of other packages issue

[Pacho Ramos]

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

El mié, 06-06-2012 a las 02:51 +0200, Michael Weber escribió:
[...]
> 
> [1] if you forget the -X on module-rebuild, you might no longer have
> the virtualbox-modules version installed in the tree (no packages
> satisfy ...). virtualbox does remove old versions real quick.
> 
> The fun part comes with non-root users trying to log in:

Yeah, I also had a similar problem with nvidia-drivers, maybe
module-rebuild should default to "-X" behavior, or is there any reason
why forcing the current behavior is better? Do we really should support
by default setups that don't apply all updates (neither locally mask
unwanted newer versions) after syncing their tree?

> 
> [2] You've updated nvidia-drivers (kernel module providers in general)
> userland and kernel modules, but forget to `rmmod nvidia`, or you
> can't without terminating user sessions, it impossible to start new X
> servers due to version mismatch between userland and kernel (applies
> for virtualbox as well)
> 

Maybe if we were able to call "rmmod -w nvidia" from nvidia-drivers
ebuild... that way, once you log out from X, old module would be
outloaded and new one loaded by X when restarting. The problem is that
there is no way to run this command after emerge "automatically"

> [3] You've updated zlib, but failed to recognize it in the emerge -av
> output. You get angry reports about broken luatex and inkscape
> (imagemagik) because of some nasty zlib abi version mismatch, hidden
> from revdep-rebuild.
> 
> [5] lafilefixer (funny)

I am not sure if this is still needed these days :-/, at least portage
looks to fix them, but I think this is not supported on other PMs (or
maybe they handle this other way apart from lafilefixer also) 

> [4] python-updater (rare)
> [6] ocaml gets broken after update w/o lablgl rebuild
>   https://bugs.gentoo.org/385869
> 
> Well, I'm lazy, and do this in the backgound, half asleep.
> And I admit that [1] and [2] are my faults, but [3] is very annoying
> (just like libdl related stuff) and esp. kernel+module updates take a
> lot more than just a few 'REBUILD' packages.
> 
> 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 understand the urge for `eupdate` but that needs an agreement on
> the implementation, and I see some rought edges here, where unattended
> script magic most likely fails.
> 
> Michael -- half asleep
> 
> - --
> Gentoo Dev
> http://xmw.de/


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

Re: [gentoo-dev] [gentoo-portage-dev] About forcing rebuilds of other packages issue

[Fabian Groffen]

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

Replying to this email since it seems to be the discussion behind
the "sub-slot" feature proposed for EAPI 5.

On 04-06-2012 23:26:18 +0200, Pacho Ramos wrote:
> 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.

After reading this thread, I have seen numerous occasions where has been
asked what this proposal actually solves.  Unless I've accidentially
skipped over it, the answer has yet to be given.  It appears to me now
sub-slot is a feature that makes it easy to express a situation that
could be expressed today as well, but requiring more work.  As such
"syntactic sugar", it seems not well bounded, allowing possibly for
doing things that result in a big mess (I cannot prove this atm, and
there is no specification afaict.)

So, I'm looking for a specification what the components in the sub-slot
exactly mean, and what behaviour they trigger.  To me, it seems right
now that sub-slot is simply ${SLOT}/${PV}, and some fancy sub-part
matching (up to the '/' actually).  It would be nice to have a sound and
clear definition of that the SLOT value means, and what the sub-slot
value means.  How can one make it up?  Could one also just start with 1
as sub-slot?  Or use names?  (SLOT="2/$(use fnord && echo fnord)").  I
have no clue how to use this correctly, as well as what problems I
should have that it solves.

To clarify the last bit, could you please explain how the following
situation benefits from sub-slot.

Consider the packages libfnord, foo and bar.  libfnord being a library,
used by foo and bar, which are simple executables.  libfnord has 6
versions (not necessarily all at the same time in the tree), with ELF
soname and library versions:

  libfnord-1        libfnord.so.3       libfnord.so.3.0
  libfnord-2        libfnord.so.5       libfnord.so.5.1
  libfnord-2.1      libfnord.so.5       libfnord.so.5.2
  libfnord-2.1-r5   libfnord.so.5       libfnord.so.5.2
  libfnord-3        libfnord.so.5       libfnord.so.5.8
  libfnord-3.5      libfnord.so.5       libfnord.so.5.12

Package foo and bar have the following versions and {,R}DEPEND:

  foo-3.0           >=libfnord-2
  bar-1.234b        =libfnord-1*
  bar-2.4           >=libfnord-3

How would the SLOT and {,R}DEPEND values for these ebuilds look like,
what happens when libfnord 2 and 3 are introduced in the tree, etc.
Please show for both EAPI 4, EAPI 4+slot-deps and EAPI 4+sub-slot.
What if libfnord-2.1 or libfnord-3.5 would be masked due to some problem
not noticed prior to stabling that makes it useless for many users.
bar-2.4 during configure checks for a new function in libfnord-3.5 and
uses it if available, or uses an alternative code-path instead.
libfnord-2.1-r5 fixes a crash in some function of the library.
(Note: this whole example/question sounds like an ebuild-quiz question
that any dev should be able to answer then.)

What would be the advantage of sub-slot here, assuming the versioning of
the libraries follows ABI versioning rules defined by e.g. libtool.


Please enlighten me.
Fabian

-- 
Fabian Groffen
Gentoo on a different level

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] [gentoo-portage-dev] About forcing rebuilds of other packages issue

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 06/09/12 05:01 AM, Fabian Groffen wrote:
> Replying to this email since it seems to be the discussion behind 
> the "sub-slot" feature proposed for EAPI 5.
> 
> On 04-06-2012 23:26:18 +0200, Pacho Ramos wrote:
>> 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.
> 
> After reading this thread, I have seen numerous occasions where has
> been asked what this proposal actually solves.  Unless I've
> accidentially skipped over it, the answer has yet to be given.  It
> appears to me now sub-slot is a feature that makes it easy to
> express a situation that could be expressed today as well, but
> requiring more work.  As such "syntactic sugar", it seems not well
> bounded, allowing possibly for doing things that result in a big
> mess (I cannot prove this atm, and there is no specification
> afaict.)
> 

#1 - there is both a specification, and an initial implementation, AND
a fork of the tree that is kept semi-up-to-date on my dev overlay.  So
please test away.  At present sub-slots have been set on Xorg
(automatically rebuilding x11-drivers/* on upgrades), and on perl
(automatically rebuilding everything (afaik) that perl-cleaner would
normally be needed for).  There should be more than enough work done
on my portage fork for you to be able to experiment and prove/disprove
said mess.

#2 - related to your question about what the proposal solves -- in my
opinion, the biggest thing the proposal solves is the case where we
want the ability to use SLOTs in the tree to manage and track
dependency changes (ie, when an API or ABI has changed), but NOT allow
multiple versions of a package to be installed at the same time.
Further to this, it allows PMs to determine what needs to be rebuilt
due to the old (no longer existing) dep being supported prior to said
dep actually being removed.



> So, I'm looking for a specification what the components in the
> sub-slot exactly mean, and what behaviour they trigger.  To me, it
> seems right now that sub-slot is simply ${SLOT}/${PV}, and some
> fancy sub-part matching (up to the '/' actually).  It would be nice
> to have a sound and clear definition of that the SLOT value means,
> and what the sub-slot value means.  How can one make it up?  Could
> one also just start with 1 as sub-slot?  Or use names?
> (SLOT="2/$(use fnord && echo fnord)").  I have no clue how to use
> this correctly, as well as what problems I should have that it
> solves.

sub-slots is the 'some-identifier' part of ${SLOT}/${some-identifier}.
 It doesn't have to replate to ${PV} at all, and generally shouldn't.
 More likely it should relate to the ${major}.${minor} in the main
library's SONAME.  For non-libtool dependencies some other form of id
is used, ie for perl I used the major.minor from $PV.



> 
> To clarify the last bit, could you please explain how the
> following situation benefits from sub-slot.
> 
> Consider the packages libfnord, foo and bar.  libfnord being a
> library, used by foo and bar, which are simple executables.
> libfnord has 6 versions (not necessarily all at the same time in
> the tree), with ELF soname and library versions:
> 
> libfnord-1        libfnord.so.3       libfnord.so.3.0 libfnord-2
> libfnord.so.5       libfnord.so.5.1 libfnord-2.1      libfnord.so.5
> libfnord.so.5.2 libfnord-2.1-r5   libfnord.so.5
> libfnord.so.5.2 libfnord-3        libfnord.so.5
> libfnord.so.5.8 libfnord-3.5      libfnord.so.5
> libfnord.so.5.12
> 
> Package foo and bar have the following versions and {,R}DEPEND:
> 
> foo-3.0           >=libfnord-2 bar-1.234b        =libfnord-1* 
> bar-2.4           >=libfnord-3
> 
> How would the SLOT and {,R}DEPEND values for these ebuilds look
> like, what happens when libfnord 2 and 3 are introduced in the
> tree, etc. Please show for both EAPI 4, EAPI 4+slot-deps and EAPI
> 4+sub-slot.

EAPI="4-slot-deps" is new to me; the implementation i've been testing
is EAPI="4-slot-abi" which is sub-slots and slot operators.  This is
the spec that was written and proposed for EAPI=5 and so this is what
i'll use to describe the above.

First, assuming currently libfnord is SLOT=0, and that there are no
ABI/API breakages on libfnord-2 through libfnord-3.5, I would just use
the ${major} version from the SONAME for the sub-slot. IE:

libfnord-1:SLOT="0/3"
libfnord-2:SLOT="0/5"
libfnord-2.1:SLOT="0/5"
...
libfnord-3.5:SLOT="0/5"


And then, assuming that foo and bar both link in the usual way, IE
they link against libfnord.so.3 instead of just libfnord.so , they
both would RDEPEND as follows:

RDEPEND="app-cat/libfnord:="


> (numeric indicators added): [1]What if libfnord-2.1 or libfnord-3.5
> would be masked due to some problem not noticed prior to stabling
> that makes it useless for many users. [2]bar-2.4 during configure
> checks for a new function in libfnord-3.5 and uses it if available,
> or uses an alternative code-path instead. [3]libfnord-2.1-r5 fixes
> a crash in some function of the library. (Note: this whole
> example/question sounds like an ebuild-quiz question that any dev
> should be able to answer then.)
> 
> What would be the advantage of sub-slot here, assuming the
> versioning of the libraries follows ABI versioning rules defined by
> e.g. libtool.

[1] No advantage as sub-slots wouldn't relate to this, UNLESS the
masking would then remove -all- SLOT="0/5" versions from the tree.  In
that case, the old SLOT="0/3" provider would be the 'upgrade' path and
so 'foo' and 'bar' would be triggered for rebuild (since the lib they
were linked to would be disappearing during emerge -uDN)

[2] In this case, the new ABI/API offering in libfnord-3.5 would need
to be addressed in the SLOT, ie, SLOT="0/5.12".  As such when
libfnord-3.5 would be upgraded then bar-2.4 (if it was already emerged
of course) would be triggered for rebuild.  'foo' would afaik also be
triggered for rebuild, though, as (at present) there isn't a way to
match partial sub-slots (or sub-sub-slots, as it were) via the slot
operators := and :*.

[3] No advantage, as linking would be consistent.  Sub-slots wouldn't
be needed in this case, and afaict updating libfnord-2.1 to
libfnord-2.1-r5 wouldn't trigger revdep-rebuild or require any
additional mediation anyways.

Hope this helps clear things up..

Ian

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlBIpGEACgkQ2ugaI38ACPBAAAD/T7kE+KkCJ2IfeHOmP/WYb+CX
ofEfsqWXZ2L0aNWDoZIA/0MeHvdH3Yul/SayBbg1Z1Etmiv6vt7f2QqBPArAl/L8
=pLhN
-----END PGP SIGNATURE-----

[EDIT] Re: [gentoo-dev] [gentoo-portage-dev] About forcing rebuilds of other packages issue

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 06/09/12 09:25 AM, Ian Stakenvicius wrote:
> 
> sub-slots is the 'some-identifier' part of
> ${SLOT}/${some-identifier}. It doesn't have to *replate* to ${PV}
> at all, and generally shouldn't.
> 
> 

..i have no idea what "replate" was supposed to be.  I think i meant
to type "equate"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlBIpX4ACgkQ2ugaI38ACPC0jwD6A6PMqQHV/8sWZnqSm2hF/plD
iBrZRvAxH7T0YdjQKeMA/02YFiom8mHs0GUDKUe18PkzM5aBlGKbnYyYcwcD3eOO
=1cGg
-----END PGP SIGNATURE-----

Re: [gentoo-dev] [gentoo-portage-dev] About forcing rebuilds of other packages issue

[Fabian Groffen]

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

On 06-09-2012 09:25:53 -0400, Ian Stakenvicius wrote:
> #1 - there is both a specification, and an initial implementation, AND
> a fork of the tree that is kept semi-up-to-date on my dev overlay.

I was interested in a (formal) specification, not a proof of concept.

> #2 - related to your question about what the proposal solves -- in my
> opinion, the biggest thing the proposal solves is the case where we
> want the ability to use SLOTs in the tree to manage and track
> dependency changes (ie, when an API or ABI has changed), but NOT allow
> multiple versions of a package to be installed at the same time.
> Further to this, it allows PMs to determine what needs to be rebuilt
> due to the old (no longer existing) dep being supported prior to said
> dep actually being removed.

...

> sub-slots is the 'some-identifier' part of ${SLOT}/${some-identifier}.
>  It doesn't have to replate to ${PV} at all, and generally shouldn't.
>  More likely it should relate to the ${major}.${minor} in the main
> library's SONAME.  For non-libtool dependencies some other form of id
> is used, ie for perl I used the major.minor from $PV.

> EAPI="4-slot-deps" is new to me; the implementation i've been testing

You refer to it lateron, so it seems to me you're unaware your sub-slots
and slot-deps are made as one commit [1].

> is EAPI="4-slot-abi" which is sub-slots and slot operators.  This is
> the spec that was written and proposed for EAPI=5 and so this is what
> i'll use to describe the above.

both are proposed for EAPI=5 [2]

> First, assuming currently libfnord is SLOT=0, and that there are no
> ABI/API breakages on libfnord-2 through libfnord-3.5, I would just use
> the ${major} version from the SONAME for the sub-slot. IE:
> 
> libfnord-1:SLOT="0/3"
> libfnord-2:SLOT="0/5"
> libfnord-2.1:SLOT="0/5"
> ...
> libfnord-3.5:SLOT="0/5"
> 
> And then, assuming that foo and bar both link in the usual way, IE
> they link against libfnord.so.3 instead of just libfnord.so , they

SONAME indeed refers to the versioned lib, although linking is of course
done against libfnord.so (-lfnord).

> both would RDEPEND as follows:
> 
> RDEPEND="app-cat/libfnord:="

This is "Slot operator dependencies" syntax.

> > (numeric indicators added): [1]What if libfnord-2.1 or libfnord-3.5
> > would be masked due to some problem not noticed prior to stabling
> > that makes it useless for many users. [2]bar-2.4 during configure
> > checks for a new function in libfnord-3.5 and uses it if available,
> > or uses an alternative code-path instead. [3]libfnord-2.1-r5 fixes
> > a crash in some function of the library. (Note: this whole
> > example/question sounds like an ebuild-quiz question that any dev
> > should be able to answer then.)
> > 
> > What would be the advantage of sub-slot here, assuming the
> > versioning of the libraries follows ABI versioning rules defined by
> > e.g. libtool.
> 
> [1] No advantage as sub-slots wouldn't relate to this, UNLESS the
> masking would then remove -all- SLOT="0/5" versions from the tree.  In
> that case, the old SLOT="0/3" provider would be the 'upgrade' path and
> so 'foo' and 'bar' would be triggered for rebuild (since the lib they
> were linked to would be disappearing during emerge -uDN)

So your example SLOTs are wrong, and should have included the minor
(always!?!) since downgrading a lib that goes back to an older minor
means functions no longer exist, thus a consumer can potentially break.

> [2] In this case, the new ABI/API offering in libfnord-3.5 would need
> to be addressed in the SLOT, ie, SLOT="0/5.12".  As such when
> libfnord-3.5 would be upgraded then bar-2.4 (if it was already emerged
> of course) would be triggered for rebuild.  'foo' would afaik also be
> triggered for rebuild, though, as (at present) there isn't a way to
> match partial sub-slots (or sub-sub-slots, as it were) via the slot
> operators := and :*.

So you basically say: this is slot-dep, you store that bar-2.4 uses
libfnord-2.1.

> [3] No advantage, as linking would be consistent.  Sub-slots wouldn't
> be needed in this case, and afaict updating libfnord-2.1 to
> libfnord-2.1-r5 wouldn't trigger revdep-rebuild or require any
> additional mediation anyways.

Yes.

> Hope this helps clear things up..

I think I understand why ciaramn suggested the use of / iso SUB_SLOT (or
something like that) here.

Could you give an example where implicit ${PV} as sub-slot would not do
what you need?

Do you allow sub-slot to depend on e.g. USE-flags in use?  Suppose
libfnord has a USE-flag cow that adds special cow interfaces to the
ABI/API.  Would SLOT="X/${PV}$(use cow && echo -- -cow)" work?
(I think SLOT is supposed to be metadata-static, but does the sub-slot
part count to that?)


[1] http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=e4ba8f36e6a4624f4fec61c7ce8bed0e3bd2fa01
[2] http://wiki.gentoo.org/wiki/EAPI_5_tentative_features

-- 
Fabian Groffen
Gentoo on a different level

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] [gentoo-portage-dev] About forcing rebuilds of other packages issue

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 07/09/12 01:13 PM, Fabian Groffen wrote:
> On 06-09-2012 09:25:53 -0400, Ian Stakenvicius wrote:
>> #1 - there is both a specification, and an initial
>> implementation, AND a fork of the tree that is kept
>> semi-up-to-date on my dev overlay.
> 
> I was interested in a (formal) specification, not a proof of
> concept.
> 

Ahh..  sorry, i figured the modified slot-operator spec that Ciaran
and Zac did was considered formal.  Are you looking for a GLEP, then?
 or...


>> #2 - related to your question about what the proposal solves --
>> in my opinion, the biggest thing the proposal solves is the case
>> where we want the ability to use SLOTs in the tree to manage and
>> track dependency changes (ie, when an API or ABI has changed),
>> but NOT allow multiple versions of a package to be installed at
>> the same time. Further to this, it allows PMs to determine what
>> needs to be rebuilt due to the old (no longer existing) dep being
>> supported prior to said dep actually being removed.
> 
> ...
> 
>> sub-slots is the 'some-identifier' part of
>> ${SLOT}/${some-identifier}. It doesn't have to replate to ${PV}
>> at all, and generally shouldn't. More likely it should relate to
>> the ${major}.${minor} in the main library's SONAME.  For
>> non-libtool dependencies some other form of id is used, ie for
>> perl I used the major.minor from $PV.
> 
>> EAPI="4-slot-deps" is new to me; the implementation i've been
>> testing
> 
> You refer to it lateron, so it seems to me you're unaware your
> sub-slots and slot-deps are made as one commit [1].
> 

if you s/slot-deps/slot-operators/ , then yes i'm aware.  to me,
"slot-deps" is something we got in (iirc) EAPI=2.



>> is EAPI="4-slot-abi" which is sub-slots and slot operators.  This
>> is the spec that was written and proposed for EAPI=5 and so this
>> is what i'll use to describe the above.
> 
> both are proposed for EAPI=5 [2]
> 
>> First, assuming currently libfnord is SLOT=0, and that there are
>> no ABI/API breakages on libfnord-2 through libfnord-3.5, I would
>> just use the ${major} version from the SONAME for the sub-slot.
>> IE:
>> 
>> libfnord-1:SLOT="0/3" libfnord-2:SLOT="0/5" 
>> libfnord-2.1:SLOT="0/5" ... libfnord-3.5:SLOT="0/5"
>> 
>> And then, assuming that foo and bar both link in the usual way,
>> IE they link against libfnord.so.3 instead of just libfnord.so ,
>> they
> 
> SONAME indeed refers to the versioned lib, although linking is of
> course done against libfnord.so (-lfnord).
> 

When looking at the output of 'scanelf -n' on a binary or library,
dependent libs seem usually to be linked against libfnord.so.X rather
than libfnord.so ; hence the breakage when upgrading from a
libfnord.so.3 provider to a libfnord.so.5 provider.  I'm sure you're
aware of that, just trying to clarify what I meant above.


>> both would RDEPEND as follows:
>> 
>> RDEPEND="app-cat/libfnord:="
> 
> This is "Slot operator dependencies" syntax.
> 

...and?

>>> (numeric indicators added): [1]What if libfnord-2.1 or
>>> libfnord-3.5 would be masked due to some problem not noticed
>>> prior to stabling that makes it useless for many users.
>>> [2]bar-2.4 during configure checks for a new function in
>>> libfnord-3.5 and uses it if available, or uses an alternative
>>> code-path instead. [3]libfnord-2.1-r5 fixes a crash in some
>>> function of the library. (Note: this whole example/question
>>> sounds like an ebuild-quiz question that any dev should be able
>>> to answer then.)
>>> 
>>> What would be the advantage of sub-slot here, assuming the 
>>> versioning of the libraries follows ABI versioning rules
>>> defined by e.g. libtool.
>> 
>> [1] No advantage as sub-slots wouldn't relate to this, UNLESS
>> the masking would then remove -all- SLOT="0/5" versions from the
>> tree.  In that case, the old SLOT="0/3" provider would be the
>> 'upgrade' path and so 'foo' and 'bar' would be triggered for
>> rebuild (since the lib they were linked to would be disappearing
>> during emerge -uDN)
> 
> So your example SLOTs are wrong, and should have included the
> minor (always!?!) since downgrading a lib that goes back to an
> older minor means functions no longer exist, thus a consumer can
> potentially break.
> 

If those (missing) functions are necessary then the either the full
slot, or the particular minimum package version, of libfnord would
need to be specified in the consumer.  This isn't any different from
how things work now.

IE, if foo works fine when being built against either libfnord-1 or
libfnord-2 , then the := slot operator will trigger a rebuild when
libfnord upgrades or downgrades.  That's its point.  If foo needs
functions that only libfnord-2 provides then it needs a dep of
> =libfnord-2 , or alternatively libfnord:0/5 .


>> [2] In this case, the new ABI/API offering in libfnord-3.5 would
>> need to be addressed in the SLOT, ie, SLOT="0/5.12".  As such
>> when libfnord-3.5 would be upgraded then bar-2.4 (if it was
>> already emerged of course) would be triggered for rebuild.  'foo'
>> would afaik also be triggered for rebuild, though, as (at
>> present) there isn't a way to match partial sub-slots (or
>> sub-sub-slots, as it were) via the slot operators := and :*.
> 
> So you basically say: this is slot-dep, you store that bar-2.4
> uses libfnord-2.1.
> 

No, we store that bar-2.4 uses libfnord:0/5

This is why, for the rebuild of bar-2.4 to be triggered on upgrade to
libfnord-3.5 the SLOT= var within libfnord-3.5.ebuild would need to
have something other than SLOT="0/5", ie, SLOT="0/5.12"



>> [3] No advantage, as linking would be consistent.  Sub-slots
>> wouldn't be needed in this case, and afaict updating libfnord-2.1
>> to libfnord-2.1-r5 wouldn't trigger revdep-rebuild or require
>> any additional mediation anyways.
> 
> Yes.
> 
>> Hope this helps clear things up..
> 
> I think I understand why ciaramn suggested the use of / iso
> SUB_SLOT (or something like that) here.
> 
> Could you give an example where implicit ${PV} as sub-slot would
> not do what you need?


Explicit ${PV} would result in needless rebuilds due to sub-slot
changes in your libfnord example above.  IE, there is no reason for a
package that has a basic RDEPEND="app-cat/libfnord:=" to be rebuilt
except when libfnord is upgraded from libfnord-1 to >libfnord-1 ;
whereas if ${PV} -were- to be the sub-slot, then rebuilds would happen
on every version bump.


> 
> Do you allow sub-slot to depend on e.g. USE-flags in use?  Suppose 
> libfnord has a USE-flag cow that adds special cow interfaces to
> the ABI/API.  Would SLOT="X/${PV}$(use cow && echo -- -cow)" work? 
> (I think SLOT is supposed to be metadata-static, but does the
> sub-slot part count to that?)

No, afaik slots (including sub-slots) can't be dynamic.  Plus we
already have comprehensive use deps solutions so why would we need that?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlBKNBwACgkQ2ugaI38ACPBsOQEAsFeayfviF743E9+6M06nRFiN
Zoz58P1VIIUxR8QdqEoA/RU7OaoIlMDbTOAwuxIuRY2lj0hUI2zVfCk09u58l1Yv
=zKWs
-----END PGP SIGNATURE-----

[gentoo-dev] Re: sub-slots (for EAPI 5)

[Fabian Groffen]

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

On 07-09-2012 13:51:24 -0400, Ian Stakenvicius wrote:
> On 07/09/12 01:13 PM, Fabian Groffen wrote:
> > On 06-09-2012 09:25:53 -0400, Ian Stakenvicius wrote:
> >> #1 - there is both a specification, and an initial
> >> implementation, AND a fork of the tree that is kept
> >> semi-up-to-date on my dev overlay.
> > 
> > I was interested in a (formal) specification, not a proof of
> > concept.
> > 
> 
> Ahh..  sorry, i figured the modified slot-operator spec that Ciaran
> and Zac did was considered formal.  Are you looking for a GLEP, then?
>  or...

No, not a GLEP, per se.  I'm trying to understand what sub-slot does and
is.  I think I'm starting to understand now.  However, for this feature
to be added to an EAPI, IMO it would be nice if there are resources that
make it for most developers very clear how this feature should be used
(and how not), and what kind of problems it can solve.

I guess real-life examples, more extensively described than you did
before, with exactly where it goes wrong, and how the situation is
improved would help.

> if you s/slot-deps/slot-operators/ , then yes i'm aware.  to me,
> "slot-deps" is something we got in (iirc) EAPI=2.

The wiki calls it "Slot operator dependencies", which I abbreviate dto
slot-deps.  Sorry for the confusion.

> >> [1] No advantage as sub-slots wouldn't relate to this, UNLESS
> >> the masking would then remove -all- SLOT="0/5" versions from the
> >> tree.  In that case, the old SLOT="0/3" provider would be the
> >> 'upgrade' path and so 'foo' and 'bar' would be triggered for
> >> rebuild (since the lib they were linked to would be disappearing
> >> during emerge -uDN)
> > 
> > So your example SLOTs are wrong, and should have included the
> > minor (always!?!) since downgrading a lib that goes back to an
> > older minor means functions no longer exist, thus a consumer can
> > potentially break.
> 
> If those (missing) functions are necessary then the either the full
> slot, or the particular minimum package version, of libfnord would
> need to be specified in the consumer.  This isn't any different from
> how things work now.

Eh, no.  Now it just always breaks when you perform a downgrade, and
revdev-rebuild or @preserved-libs won't help you.  I prefer that you
give best practices how to use sub-slots to make Portage also able to do
a recompile of bar when libfnord in the same SLOT gets downgraded.
(Because minors are used for compatible changes -- additions -- to the
ABI.)
(And the recompile is preferably done against the headers of the
downgraded version, but with the newer version's lib still around, such
that if this is a vital binary such as Python, it will not break down --
however, this is most likely too much to ask.)

> This is why, for the rebuild of bar-2.4 to be triggered on upgrade to
> libfnord-3.5 the SLOT= var within libfnord-3.5.ebuild would need to
> have something other than SLOT="0/5", ie, SLOT="0/5.12"

Yeah, but can I also avoid bar-2.4 being recompiled when I install
libfnord-3.5?  It's not necessary, because the 5-ABI of libfnord is
supposed to be backwards compatible.  (At least that's the idea.)
Like mentioned before, I DO want bar-2.4 to be recompiled if I have to
downgrade libfnord to a version before the one I had installed when I
compiled bar-2.4, though.

> > Do you allow sub-slot to depend on e.g. USE-flags in use?  Suppose 
> > libfnord has a USE-flag cow that adds special cow interfaces to
> > the ABI/API.  Would SLOT="X/${PV}$(use cow && echo -- -cow)" work? 
> > (I think SLOT is supposed to be metadata-static, but does the
> > sub-slot part count to that?)
> 
> No, afaik slots (including sub-slots) can't be dynamic.  Plus we
> already have comprehensive use deps solutions so why would we need that?

Because the ABI changes.  But I guess you're right that we can safely
ignore packages that screw it up badly enough here.

Thanks

-- 
Fabian Groffen
Gentoo on a different level

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Re: sub-slots (for EAPI 5)

[Ciaran McCreesh]

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

On Fri, 7 Sep 2012 20:17:17 +0200
Fabian Groffen <grobian@gentoo.org> wrote:
> Eh, no.  Now it just always breaks when you perform a downgrade, and
> revdev-rebuild or @preserved-libs won't help you.  I prefer that you
> give best practices how to use sub-slots to make Portage also able to
> do a recompile of bar when libfnord in the same SLOT gets downgraded.
> (Because minors are used for compatible changes -- additions -- to the
> ABI.)

Downgrades aren't covered by sub-slots, slots, regular dependencies,
libtool, or anything else.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Re: sub-slots (for EAPI 5)

[Fabian Groffen]

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

On 07-09-2012 19:21:57 +0100, Ciaran McCreesh wrote:
> On Fri, 7 Sep 2012 20:17:17 +0200
> Fabian Groffen <grobian@gentoo.org> wrote:
> > Eh, no.  Now it just always breaks when you perform a downgrade, and
> > revdev-rebuild or @preserved-libs won't help you.  I prefer that you
> > give best practices how to use sub-slots to make Portage also able to
> > do a recompile of bar when libfnord in the same SLOT gets downgraded.
> > (Because minors are used for compatible changes -- additions -- to the
> > ABI.)
> 
> Downgrades aren't covered by sub-slots, slots, regular dependencies,
> libtool, or anything else.

It seems I mistakenly took slot-operator-deps and sub-slots as something
that can be mapped onto ABIs.  Doing so, however has proven to be wrong.

It appears slot-operator-deps do have some resemblance with ABI here
(especially if :* would be written in PMS such that it only allows
upgrades, no downgrades), but sub-slots are completely unrelated.

I don't like the mixing of the two in a single var, at all.  I think I'd
much more prefer Portage to understand ABIs and potentially versions, to
make it explicit why it is doing what.


-- 
Fabian Groffen
Gentoo on a different level

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Re: sub-slots (for EAPI 5)

[Ciaran McCreesh]

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

On Fri, 7 Sep 2012 20:49:35 +0200
Fabian Groffen <grobian@gentoo.org> wrote:
> On 07-09-2012 19:21:57 +0100, Ciaran McCreesh wrote:
> > On Fri, 7 Sep 2012 20:17:17 +0200
> > Fabian Groffen <grobian@gentoo.org> wrote:
> > > Eh, no.  Now it just always breaks when you perform a downgrade,
> > > and revdev-rebuild or @preserved-libs won't help you.  I prefer
> > > that you give best practices how to use sub-slots to make Portage
> > > also able to do a recompile of bar when libfnord in the same SLOT
> > > gets downgraded. (Because minors are used for compatible changes
> > > -- additions -- to the ABI.)
> > 
> > Downgrades aren't covered by sub-slots, slots, regular dependencies,
> > libtool, or anything else.
> 
> It seems I mistakenly took slot-operator-deps and sub-slots as
> something that can be mapped onto ABIs.  Doing so, however has proven
> to be wrong.

It's not entirely wrong. There's a reason we stopped using the word
"ABI", though: it's a meaningless term with a lot of misleading
connotations.

> It appears slot-operator-deps do have some resemblance with ABI here
> (especially if :* would be written in PMS such that it only allows
> upgrades, no downgrades), but sub-slots are completely unrelated.

Downgrades are a different, unrelated problem. If you're trying to
solve that, you'll need a different, orthogonal solution. Note, though,
that downgrade breakages are typically not covered by whatever you think
an ABI is.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Re: sub-slots (for EAPI 5)

[Fabian Groffen]

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

On 07-09-2012 19:55:53 +0100, Ciaran McCreesh wrote:
> > It appears slot-operator-deps do have some resemblance with ABI here
> > (especially if :* would be written in PMS such that it only allows
> > upgrades, no downgrades), but sub-slots are completely unrelated.
> 
> Downgrades are a different, unrelated problem. If you're trying to
> solve that, you'll need a different, orthogonal solution. Note, though,
> that downgrade breakages are typically not covered by whatever you think
> an ABI is.

I don't really want to solve downgrades.  I just want to fully
understand what slot-deps is supposed to do, and what not.
It seems I fail in doing so.


-- 
Fabian Groffen
Gentoo on a different level

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Re: sub-slots (for EAPI 5)

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 07/09/12 02:17 PM, Fabian Groffen wrote:
> 
> No, not a GLEP, per se.  I'm trying to understand what sub-slot
> does and is.  I think I'm starting to understand now.  However, for
> this feature to be added to an EAPI, IMO it would be nice if there
> are resources that make it for most developers very clear how this
> feature should be used (and how not), and what kind of problems it
> can solve.
> 
> I guess real-life examples, more extensively described than you
> did before, with exactly where it goes wrong, and how the situation
> is improved would help.
> 

I agree; I expect devmanual.gentoo.org would need a nice big page (or
section in the SLOTs page) describing it, if not at the very least a
nice entry on wiki.g.o


>>>> [1] No advantage as sub-slots wouldn't relate to this,
>>>> UNLESS the masking would then remove -all- SLOT="0/5"
>>>> versions from the tree.  In that case, the old SLOT="0/3"
>>>> provider would be the 'upgrade' path and so 'foo' and 'bar'
>>>> would be triggered for rebuild (since the lib they were
>>>> linked to would be disappearing during emerge -uDN)
>>> 
>>> So your example SLOTs are wrong, and should have included the 
>>> minor (always!?!) since downgrading a lib that goes back to an 
>>> older minor means functions no longer exist, thus a consumer
>>> can potentially break.
>> 
>> If those (missing) functions are necessary then the either the
>> full slot, or the particular minimum package version, of libfnord
>> would need to be specified in the consumer.  This isn't any
>> different from how things work now.
> 
> Eh, no.  Now it just always breaks when you perform a downgrade,
> and revdev-rebuild or @preserved-libs won't help you.  I prefer
> that you give best practices how to use sub-slots to make Portage
> also able to do a recompile of bar when libfnord in the same SLOT
> gets downgraded. (Because minors are used for compatible changes --
> additions -- to the ABI.) (And the recompile is preferably done
> against the headers of the downgraded version, but with the newer
> version's lib still around, such that if this is a vital binary
> such as Python, it will not break down -- however, this is most
> likely too much to ask.)
> 

I guess maybe i'm not following your example.  To spell it out better,
here's what I'm understanding:

bar-1.0 has (prior to slot-operators) an RDEPEND="app-cat/libfnord".
No version specified.  As such, it'll build successfully against
either libfnord-1 or libfnord-2.  Right now (as i understand it) a
downgrade from libfnord-2 to libfnord-1 would "break" bar-1.0 bot
revdep-rebuild would detect and fix it.

sub-slots + slot-operators would alleviate what I just described,
auto-rebuilding bar (at least that's the theory; i've had some issues
getting portage to downgrade things even with regular slots so some
work on the implementation might be needed with this, dunno)

*IF* on the other hand, you're referring to the case of libfnord-2.1
downgrading to libfnord-2 , then yes I can see how bar-1.0 would be
broken and revdep-rebuild wouldn't fix it.  However, as far as I
understand it, proper LTVERSIONing should mean that bar wouldn't break
as anything which would break bar on a libfnord-2 downgrade shouldn't
be used by bar in libfnord-2.1 -- ie, the differences would be
internal to libfnord and not directly used by bar.

If a package is -not- properly LTVERSIONed though, sub-slot bumps
could help alleviate this issue at the ebuild level.


>> This is why, for the rebuild of bar-2.4 to be triggered on
>> upgrade to libfnord-3.5 the SLOT= var within libfnord-3.5.ebuild
>> would need to have something other than SLOT="0/5", ie,
>> SLOT="0/5.12"
> 
> Yeah, but can I also avoid bar-2.4 being recompiled when I install 
> libfnord-3.5?  It's not necessary, because the 5-ABI of libfnord
> is supposed to be backwards compatible.  (At least that's the
> idea.) Like mentioned before, I DO want bar-2.4 to be recompiled if
> I have to downgrade libfnord to a version before the one I had
> installed when I compiled bar-2.4, though.
> 

Sure -- since bar-2.4 does support a codepath for <libfnord-3.5,
there's no reason to rebuild bar-2.4 to enforce it afaict.

As for the downgrade, bar-2.4 should link against libfnord.so.5.12
rather than libfnord.so.5 due to the LTVERSION-specific codepath I
think; and I also think that sub-slots couldn't be used to trigger the
rebuild on downgrade if there shouldn't be a rebuild on upgrade;
@preserve-libs would be the only way to handle this one.


>>> Do you allow sub-slot to depend on e.g. USE-flags in use?
>>> Suppose libfnord has a USE-flag cow that adds special cow
>>> interfaces to the ABI/API.  Would SLOT="X/${PV}$(use cow &&
>>> echo -- -cow)" work? (I think SLOT is supposed to be
>>> metadata-static, but does the sub-slot part count to that?)
>> 
>> No, afaik slots (including sub-slots) can't be dynamic.  Plus we 
>> already have comprehensive use deps solutions so why would we
>> need that?
> 
> Because the ABI changes.  But I guess you're right that we can
> safely ignore packages that screw it up badly enough here.

I think that the best way to resolve something like this would be more
comprehensive use dep usage -- ie, if bar uses the bits of libfnord
available through USE="cow" then bar is effectively dependant on those
bits and so a libfnord:=[cow?] dep (and IUSE="cow" addition if not
already there) might be appropriate.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlBKP2oACgkQ2ugaI38ACPA3lAD/blxSdo1onKom/rFESPbQVWU4
bXNDbxlE28YNWTjBipkBAIxacbdMUcp8t7drd+Ldh1LULp3tEPQwIhdFPtdylGi7
=0/rQ
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: sub-slots (for EAPI 5)

[Fabian Groffen]

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

On 07-09-2012 14:39:38 -0400, Ian Stakenvicius wrote:
> I guess maybe i'm not following your example.  To spell it out better,
> here's what I'm understanding:
> 
> bar-1.0 has (prior to slot-operators) an RDEPEND="app-cat/libfnord".
> No version specified.  As such, it'll build successfully against
> either libfnord-1 or libfnord-2.  Right now (as i understand it) a
> downgrade from libfnord-2 to libfnord-1 would "break" bar-1.0 bot
> revdep-rebuild would detect and fix it.

right or portage would preserve libfnord-2's libs

> sub-slots + slot-operators would alleviate what I just described,
> auto-rebuilding bar (at least that's the theory; i've had some issues
> getting portage to downgrade things even with regular slots so some
> work on the implementation might be needed with this, dunno)
> 
> *IF* on the other hand, you're referring to the case of libfnord-2.1
> downgrading to libfnord-2 , then yes I can see how bar-1.0 would be
> broken and revdep-rebuild wouldn't fix it.  However, as far as I
> understand it, proper LTVERSIONing should mean that bar wouldn't break
> as anything which would break bar on a libfnord-2 downgrade shouldn't
> be used by bar in libfnord-2.1 -- ie, the differences would be
> internal to libfnord and not directly used by bar.

Well, yes and no.  The no applies to the case where bar works around a
missing function by e.g. implementing it itself, conditionally.  A
package maintainer might not have been aware of this, hence not
expressed this in the dependencies (e.g. requiring the version that
contains the missing function).
Anyway, we should avoid downgrades of libraries, so no need to discuss
this any further.  It doesn't break more than it does already.


-- 
Fabian Groffen
Gentoo on a different level

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Re: sub-slots (for EAPI 5)

[Zac Medico]

On 09/07/2012 11:17 AM, Fabian Groffen wrote:
> No, not a GLEP, per se.  I'm trying to understand what sub-slot does and
> is.  I think I'm starting to understand now.  However, for this feature
> to be added to an EAPI, IMO it would be nice if there are resources that
> make it for most developers very clear how this feature should be used
> (and how not), and what kind of problems it can solve.
> 
> I guess real-life examples, more extensively described than you did
> before, with exactly where it goes wrong, and how the situation is
> improved would help.

Perhaps some of the greatest frustrations for Gentoo users stem from the
lack of support for automatic rebuild of packages when necessary.
Imagine how nice it would be if necessary rebuilds would automatically
occur when appropriate, so that you wouldn't experience build failures
that require you to manually intervene by running revdep-rebuild,
perl-cleaner, or something like that. And there are other kinds of
necessary rebuilds that don't trigger build failures, but lead to
runtime failures that are noticed much later (like xorg driver failures
after a major xorg-server update). Sub-slots can be used to solve the
bulk of problems like these that our users have had to deal with manually.

> Eh, no.  Now it just always breaks when you perform a downgrade, and
> revdev-rebuild or @preserved-libs won't help you.  I prefer that you
> give best practices how to use sub-slots to make Portage also able to do
> a recompile of bar when libfnord in the same SLOT gets downgraded.
> (Because minors are used for compatible changes -- additions -- to the
> ABI.)
> (And the recompile is preferably done against the headers of the
> downgraded version, but with the newer version's lib still around, such
> that if this is a vital binary such as Python, it will not break down --
> however, this is most likely too much to ask.)

It might be worthwhile to try come up with some way to handle minor
downgrades in some later EAPI, but it adds complexity. Meanwhile,
sub-slots are a relatively simple extension to slot-operator deps, and
they are poised to greatly improve user experience (via automatic
rebuilds) if they are included in EAPI 5.
-- 
Thanks,
Zac

Re: [gentoo-dev] Re: sub-slots (for EAPI 5)

[Fabian Groffen]

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

On 07-09-2012 12:03:16 -0700, Zac Medico wrote:
> On 09/07/2012 11:17 AM, Fabian Groffen wrote:
> > I guess real-life examples, more extensively described than you did
> > before, with exactly where it goes wrong, and how the situation is
> > improved would help.
> 
> Perhaps some of the greatest frustrations for Gentoo users stem from the
> lack of support for automatic rebuild of packages when necessary.
> Imagine how nice it would be if necessary rebuilds would automatically
> occur when appropriate, so that you wouldn't experience build failures
> that require you to manually intervene by running revdep-rebuild,
> perl-cleaner, or something like that. And there are other kinds of
> necessary rebuilds that don't trigger build failures, but lead to
> runtime failures that are noticed much later (like xorg driver failures
> after a major xorg-server update). Sub-slots can be used to solve the
> bulk of problems like these that our users have had to deal with manually.

I like that!  Kudos for making it work!

I just wonder what the heck that has to do with SLOT.
This discussion has been done before in this thread, and it somehow
settled.

> ... sub-slots are a relatively simple extension to slot-operator deps,
> and they are poised to greatly improve user experience (via automatic
> rebuilds) if they are included in EAPI 5.

And we want it.  But is it a good idea to add some feature that feels
like just a hack?


-- 
Fabian Groffen
Gentoo on a different level

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Re: sub-slots (for EAPI 5)

[Ciaran McCreesh]

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

On Fri, 7 Sep 2012 21:25:22 +0200
Fabian Groffen <grobian@gentoo.org> wrote:
> I like that!  Kudos for making it work!
> 
> I just wonder what the heck that has to do with SLOT.

The correct fix for "not needing to rebuild" stuff is to SLOT libraries
like crazy, and have a SLOT per thing-we-don't-call-ABI. This then
needs := dependencies, so that packages can say "and remember which
SLOT I was built against".

However, there are some packages that cannot easily be SLOTted to the
degree that we'd like. This is where sub-SLOTs come in. Given
sub-SLOTted packages dep:1/a and dep:1/b, this says "I'd like to have
slots 1a and 1b, but it's too difficult to allow 1a and 1b to be
installed at the same time".

So suppose the user has pkg with a dependency upon dep, with slot 1 and
a := operator. They install pkg when dep:1/a is installed. The user
then installs dep:1/b. In an ideal world, dep:1/a would remain
installed in parallel with dep:1/b, but your friendly Gentoo developers
have decided it's not worth their time to allow this. Thus, dep:1/a has
to be uninstalled to allow dep:1/b to be installed. But this would
break pkg, since pkg needs dep:1/a. However, a clever dependency
resolver can note that reinstalling pkg would fix it, since dep:1/b
also satisfies pkg's slot 1 := dependency (but not the locked 1/a
dependency that the installed version of pkg has picked up).

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Re: sub-slots (for EAPI 5)

[Fabian Groffen]

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

On 07-09-2012 20:36:02 +0100, Ciaran McCreesh wrote:
> The correct fix for "not needing to rebuild" stuff is to SLOT libraries
> like crazy, and have a SLOT per thing-we-don't-call-ABI. This then
> needs := dependencies, so that packages can say "and remember which
> SLOT I was built against".
> 
> However, there are some packages that cannot easily be SLOTted to the
> degree that we'd like. This is where sub-SLOTs come in. Given
> sub-SLOTted packages dep:1/a and dep:1/b, this says "I'd like to have
> slots 1a and 1b, but it's too difficult to allow 1a and 1b to be
> installed at the same time".
> 
> So suppose the user has pkg with a dependency upon dep, with slot 1 and
> a := operator. They install pkg when dep:1/a is installed. The user
> then installs dep:1/b. In an ideal world, dep:1/a would remain
> installed in parallel with dep:1/b, but your friendly Gentoo developers
> have decided it's not worth their time to allow this. Thus, dep:1/a has
> to be uninstalled to allow dep:1/b to be installed. But this would
> break pkg, since pkg needs dep:1/a. However, a clever dependency
> resolver can note that reinstalling pkg would fix it, since dep:1/b
> also satisfies pkg's slot 1 := dependency (but not the locked 1/a
> dependency that the installed version of pkg has picked up).

Thanks.  It seems we're there.  At last.


-- 
Fabian Groffen
Gentoo on a different level

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Re: sub-slots (for EAPI 5)

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 07/09/12 03:25 PM, Fabian Groffen wrote:
> On 07-09-2012 12:03:16 -0700, Zac Medico wrote:
>> On 09/07/2012 11:17 AM, Fabian Groffen wrote:
>>> I guess real-life examples, more extensively described than you
>>> did before, with exactly where it goes wrong, and how the
>>> situation is improved would help.
>> 
>> Perhaps some of the greatest frustrations for Gentoo users stem
>> from the lack of support for automatic rebuild of packages when
>> necessary. Imagine how nice it would be if necessary rebuilds
>> would automatically occur when appropriate, so that you wouldn't
>> experience build failures that require you to manually intervene
>> by running revdep-rebuild, perl-cleaner, or something like that.
>> And there are other kinds of necessary rebuilds that don't
>> trigger build failures, but lead to runtime failures that are
>> noticed much later (like xorg driver failures after a major
>> xorg-server update). Sub-slots can be used to solve the bulk of
>> problems like these that our users have had to deal with
>> manually.
> 
> I like that!  Kudos for making it work!
> 
> I just wonder what the heck that has to do with SLOT. This
> discussion has been done before in this thread, and it somehow 
> settled.
> 
>> ... sub-slots are a relatively simple extension to slot-operator
>> deps, and they are poised to greatly improve user experience (via
>> automatic rebuilds) if they are included in EAPI 5.
> 
> And we want it.  But is it a good idea to add some feature that
> feels like just a hack?
> 
> 

Originally the sub-slot idea came about because one of the ways
"around" all of this broken-and-requiring-afterthefact-rebuilding was
to just make everything slotted -- so there would always be multiple
slots of everything installed -- and use slot-operators to indicate
when things should be re-emerged

Although this would work, the end result would (imo at least) be
horrible on-disk.

Sub-slots allow the main part of SLOT to still specify what's
installed on disk, while allowing PMS to identify and trigger rebuilds
for SLOT changes based on slot-operators.

I see it akin to the '-r' portion of ${PV} -- Used by portage to
trigger updates but having very little meaning to the actual version
of the package that gets installed. (ok i might be stretching it with
this)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlBKUK4ACgkQ2ugaI38ACPDbCAEAiG+7hQch043se8ZfDE4qC52w
79ZImWn5jazqGQDN3zsA/3B1AJR+SWxUFDHZF1LArX0r0Gd7J2madTqP0m+llxuG
=7IEF
-----END PGP SIGNATURE-----

Re: [gentoo-dev] [gentoo-portage-dev] About forcing rebuilds of other packages issue

[Zac Medico]

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

On 09/07/2012 10:13 AM, Fabian Groffen wrote:
> Could you give an example where implicit ${PV} as sub-slot would
> not do what you need?

Can you point out a package for which SONAME/ABI/whatever changes
every time ${PV} changes? Probably not. Is the relationship between
${PV} and SONAME/ABI/whatever changes the same for every package?
Absolutely not. So, we have to be able to bump the sub-slot when it's
appropriate for the particular package, and every package is different.
- -- 
Thanks,
Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlBKNEoACgkQ/ejvha5XGaOvAQCfZS/TAtDijXFox9cHi3BkjKgP
raYAoJL77bi09/dABH3brj+2LjWYbydK
=sIAY
-----END PGP SIGNATURE-----

Re: [gentoo-dev] [gentoo-portage-dev] About forcing rebuilds of other packages issue

[Fabian Groffen]

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

On 07-09-2012 10:52:10 -0700, Zac Medico wrote:
> On 09/07/2012 10:13 AM, Fabian Groffen wrote:
> > Could you give an example where implicit ${PV} as sub-slot would
> > not do what you need?
> 
> Can you point out a package for which SONAME/ABI/whatever changes
> every time ${PV} changes? Probably not. Is the relationship between
> ${PV} and SONAME/ABI/whatever changes the same for every package?
> Absolutely not. So, we have to be able to bump the sub-slot when it's
> appropriate for the particular package, and every package is different.

I'm sure there are such packages, but I guess you're right.  It's good
to have this clear.


-- 
Fabian Groffen
Gentoo on a different level

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] [gentoo-portage-dev] About forcing rebuilds of other packages issue

[Zac Medico]

On 09/06/2012 02:01 AM, Fabian Groffen wrote:
> After reading this thread, I have seen numerous occasions where has been
> asked what this proposal actually solves.  Unless I've accidentially
> skipped over it, the answer has yet to be given.  It appears to me now
> sub-slot is a feature that makes it easy to express a situation that
> could be expressed today as well, but requiring more work.  As such
> "syntactic sugar", it seems not well bounded, allowing possibly for
> doing things that result in a big mess (I cannot prove this atm, and
> there is no specification afaict.)

The sub-slot is needed for those cases where it's just not practical to
bump the regular slot. Tiziano Müller (dev-zero) has summarized the
possible solutions well [1]:

> I see four possibilities:
> 1) patch them to version the headers as well and slot them (together with slot operator deps)
> 2) ask upstream to properly version the headers alongside with the lib and slot them (together with slot operator deps)
> 3) slot them and block old slots in newer versions (together with slot operator deps)
> 4) introduce a new EAPI variable which can be incremented whenever an soname changes (needs some more thinking and proper specification, somehow duplicates SLOT)

Sub-slot implements #4 (by extending the SLOT variable instead of using
a new variable).

[1] https://bugs.gentoo.org/show_bug.cgi?id=414955#c10
-- 
Thanks,
Zac