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