Re: Update alternatives priority mismatch in openSUSE
Hi!
On Fri, 2016-04-08 at 10:33:44 +0200, Tomas Chvatal wrote:
> Ian Jackson píše v Pá 08. 04. 2016 v 01:51 +0100:
> > Tomas Chvatal writes:
> > > In SUSE we noticed that some of our python packages were not updating
> > > their alternatives when migrating from ie python2.6 to python2.7.
> > >
> > > This is due to unfortunate priority set by the maintainers of such
> > > packages to be equal between py2.6 and py2.7 while pointing to
> > > different files (eg /usr/bin/pip-2.6 vs /usr/bin/pip-2.7).
This is one among many of the reasons in Debian for most of the packages
which need to specify global distro default interfaces (such as
interpreters), to use static symlinks instead of alternatives. If the
user/admin is enouraged to change the default interpreter path then no
program can assume what's the underlying implementation providing that
interface, so they'd need to target the lowest version.
If you are going to use alternatives anyway, and you assume that
latter versions are better I'd recommend using a priority based off
the version number somehow. Of course that does not cover cases where
an independent implementation uses a different versioning scheme. :/
It's also a priority which will keep growing indefinitely.
> > > The correct fix that is being implemented is to update the priorities
> > > to be correctly bumped when this happens in the packages. But for the
> > > safer world we would also like include patch (see attachment) that
> > > forces the update even if the priorities are the same. So we can be
> > > safe against this kind of mistakes in future.
> > >
> > > Would this be acceptable for you guys to merge?
> > It's not my decision any more, but that update-alternatives prefers to
> > keep the existing state in this situation was originally my doing and
> > it was done for a good reason:
That plus something I fixed relatively recently :)
<http://anonscm.debian.org/cgit/dpkg/dpkg.git/commit/?id=7f1940a118fba31d0927d817a094ea2b41c0474f>
So applying the proposed patch would in a way revert that fix.
> > Without this, installing or upgrading packages (for example, as a
> > result of securit updates) would result in the link flapping back and
> > forth as the different packages fight over it. The end state would
> > depend on the exact upgrade order.
> >
> > So I'm afraid I think your change is a bad idea.
Yeah, I agree.
> Thanks for the review. I will try to use it only until we fix all the
> python/ruby packages we have because atm it results in quite broken
> systems without it.
Also your proposal assumes that alternatives that appear latter are
better. The code sorts them when saving so they might not always be
alphabetically sorted. And assuming that something that sorts
alphabetically latter is better is a bit adventurous. :)
> We had rule about no 2 packages to have same priority but nobody ever
> realized that changing files in the one package alone does not force
> the refresh.
I think if there are two alternatives with the same priority and one
of them is currently active, then it's saner to leave that one alone
and not touch it, as the current code is doing.
> As each package calls the script with different priority would that
> cause any problems then? I can only imagine this flapping happening if
> multiple packages have exactly same priority. When I tested it on
> selected packages (eg the one tweaked with this patch had highest
> priority it simply just redone the content of the alternative from the
> old one to the current) and if I updated package with lower priority
> than currently already available it did nothing like I would anticipate
It's precisely the comparison against equal priority which creates the
flip-flops, so I'm afraid that's not good, and in principle I'm not
planning on applying this, sorry!
But thanks for taking the time to prepare a patch and propose it
anyway, much appreciated.
Regards,
Guillem
Reply to: