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