| 1 |
On Fri, 1 Aug 2014 09:24:46 -0400 |
| 2 |
Rich Freeman <rich0@g.o> wrote: |
| 3 |
> The thing is, with @preserved-rebuild I don't have to run |
| 4 |
> revdep-rebuild for the packages that either can't be or simply aren't |
| 5 |
> migrated to slot operator deps. That is a huge win. Also, random |
| 6 |
> things aren't broken during the time that I'm rebuilding, so I don't |
| 7 |
> end up chrooting into my system from a rescue CD when I forget to run |
| 8 |
> revdep-rebuild. I'll be happy when the day comes when we can get rid |
| 9 |
> of it, but that day is not yet here. |
| 10 |
|
| 11 |
Unfortunately, like dynamic dependencies, there's a vicious feedback |
| 12 |
cycle of increasingly ugly hacks with preserved-rebuild. People start |
| 13 |
to use it, and it sometimes doesn't work, so another hack is added in |
| 14 |
to work around one thing at the expense of three others, so people |
| 15 |
carry on using it, so another hack is added in, and so on. It's not a |
| 16 |
sustainable development model, and it's not something that will be |
| 17 |
fixed by letting users and developers continue with a short-term view. |
| 18 |
|
| 19 |
> Generally speaking portage has favored usability over beauty of |
| 20 |
> design. That has made it harder to maintain, but far more popular. |
| 21 |
|
| 22 |
Portage favours usability in the case that nothing goes wrong, and it |
| 23 |
does it by making it ever more likely that something will go horribly |
| 24 |
wrong to the point that you have to give up and reinstall everything. |
| 25 |
Paludis tries hard to make sure everything is correct, at the expense |
| 26 |
that you have to invest smaller amounts of time as you go along fixing |
| 27 |
errors. The key point is, this investment would be much smaller if the |
| 28 |
quality of inputs was higher. This would be good for users, but also |
| 29 |
for developers: wouldn't you like to replace all your horrible |
| 30 |
complicated eclasses that generate perverse dependency strings with |
| 31 |
something much simpler? |
| 32 |
|
| 33 |
> And what I'm really asking for here is for somebody to actually |
| 34 |
> explain what is actually wrong with dynamic dependencies. |
| 35 |
|
| 36 |
The big issues are: |
| 37 |
|
| 38 |
* They suddenly stop working if an ebuild is removed. |
| 39 |
|
| 40 |
* They can make a 'sync' break a user's system. |
| 41 |
|
| 42 |
* They don't work with binary packages. |
| 43 |
|
| 44 |
* They don't work with overlays. |
| 45 |
|
| 46 |
* They don't work with "resurrecting" packages in overlays. |
| 47 |
|
| 48 |
* They're utterly incompatible with subslot deps. |
| 49 |
|
| 50 |
* Someone adds selinux support to foo. Then a new bar starts requiring |
| 51 |
foo[selinux]. The user hasn't rebuilt their foo to get selinux |
| 52 |
support, but the dependency is still met, thanks to dynamic |
| 53 |
dependencies. |
| 54 |
|
| 55 |
* The ruby-config example (details from memory, probably inaccurate, |
| 56 |
but the idea is right): Ruby ebuilds used to dep upon something like |
| 57 |
ruby-config, and they used it in pkg_prerm. The ebuilds were changed |
| 58 |
to use eselect-ruby instead. Users would replace ruby-config with |
| 59 |
eselect-ruby, and then be unable to uninstall or upgrade old ebuilds, |
| 60 |
because "dynamic" dependencies incorrectly changed the dependency |
| 61 |
without changing the pkg_prerm function. |
| 62 |
|
| 63 |
But most fundamentally, the idea that a thing in VDB is somehow always |
| 64 |
associated with exactly one ebuild in the tree, and that changes to |
| 65 |
that ebuild are reflected in VDB, just doesn't work except in trivial |
| 66 |
cases. |
| 67 |
|
| 68 |
-- |
| 69 |
Ciaran McCreesh |
Archives