On za, 2012-06-23 at 17:08 +0100, Ciaran McCreesh wrote: > > > Is it that Paludis installs a newer SLOT even if a reverse > dependency > > explicitly requests another SLOT? Sounds like a bug to me. > > No, it's that if a user requests a "complete" resolution, Paludis > installs the newest version of things that it can. Extensive > consultation with users has shown that this is a good behaviour, > except > in the small number of situations that have recently arisen where > people are doing weird things with versions and slots.
It surprises me that this behavior is normally desirable for packages where all dependencies (including any in the world set or the like) are slotted. The first example that comes to mind here is gtk+: if all packages a user has installed that depend on gtk+ explicitly depend on slot 2 (which is probably uncommon now but reasonable back when gtk 3 was introduced), and they do not have gtk+ in their world file (which is reasonable), do your users really expect the package manager to install gtk 3? If your package manager has a feature similar to emerge --depclean, shouldn't this then suggest immediately removing it again, as nothing depends on it? I would argue that library versions that can be installed side-by-side, like gtk+ 2 and 3, "fit the traditional way of how slots worked". But I think automatically pulling in the latest and greatest version of such a library only makes sense if code written against the old library stands a chance of making use of the new library. It might make sense to add a way to inform your package manager if pulling in new slots by default is useful, but I would prefer to give this a more obvious name than "funky-slots", and to come up with a better approach for deciding whether or not the property should be set than "is SLOTS being used for something "clever" or not". I would also suggest that the default should be to *not* pull in new slots by default, but perhaps some review of how slotting is most commonly used would help decide on that. -- Marien Zwart
