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

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

[Pacho Ramos]

[-- Attachment #1: Type: text/plain, Size: 3090 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] About forcing rebuilds of other packages issue

[Zac Medico]

On 06/04/2012 02:29 PM, Pacho Ramos wrote:
> - Looks like there is no consensus about what to do and, then, this
> could probably be implemented on eapi... 7? While former could probably
> be implemented much sooner (probably even in eapi5) 

Ciaran has been advocating "SLOT operator" dependencies for this, but
those are not designed to work with unslotted packages, which leads to
the issues discussed in bug 414955:

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

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

[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

[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

[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

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

[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

[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

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

[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

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

[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

[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

[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

[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

[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

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

[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

[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

[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

[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

[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

[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

[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

[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

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

[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

[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

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

[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

[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

[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

[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

[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

[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

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

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