Re: [gentoo-project] Re: Call for agenda items - Council meeting 2014-08-12

[Ciaran McCreesh <ciaran.mccreesh@googlemail.com>]

[-- Attachment #1: Type: text/plain, Size: 3221 bytes --]

On Fri, 1 Aug 2014 09:24:46 -0400
Rich Freeman <rich0@gentoo.org> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 181 bytes --]