On Mon, 07 Apr 2014 17:58:52 +0300
Samuli Suominen <ssuominen@gentoo.org> wrote:
> On 07/04/14 17:49, Ciaran McCreesh wrote:
> > On Mon, 07 Apr 2014 14:54:43 +0300
> > Samuli Suominen <ssuominen@gentoo.org> wrote:
> >> You can get me to change mind by writing up a policy that says
> >> dynamic deps can't be relied upon, and getting rest of the QA
> >> team, perhaps council, on board with it.
> > They can't be relied upon: they stop working as soon as you remove
> > an ebuild from the tree when the user still has that version
> > installed. They also don't work if you make changes to runtime
> > dependencies that need a reinstall or upgrade, as has happened with
> > various -config utilities.
> >
> 
> Of course if reinstall or upgrade is required, then revision bump is
> issued as normal.

But we've seen this not happen: people have had old versions of a
package installed that needed foo-config installed to do the uninstall
(e.g. pkg_postrm), and then an eclass was changed to use foo2-config
instead, and the uninstall or upgrade wouldn't work because foo-config
had incorrectly been uninstalled.

Dynamic dependencies do *not* mean dynamic pkg_* functions.

> If the version isn't anymore in Portage, then user will be upgrading
> into one that is anyway, and
> the problem becomes moot.

This isn't enforced, though. And see above: it's only moot if you
ignore all the ways it goes wrong.

> I'm aware it's not perfect, but it's the best we have.
> 
> I'm also aware of Paludis having more issues with it, than Portage,
> IIRC, which is really irrelevant since
> Portage is the official PM.    No, this is not a flamebait, and I feel
> like apologizing to you already, but that's just how I see it.
> 
> I'm arguing that working around the PM bug(s) by enforcing "a useless"
> rebuilds for everyone, is not the solution.

The bug is Portage sometimes doing dynamic deps...

-- 
Ciaran McCreesh