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