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

[Ian Stakenvicius]

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

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

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

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

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

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

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

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