2015-09-13 23:39 GMT+01:00 Edward Welbourne <e...@chaos.org.uk>:
>
>>>> I'm on testing. I have chromium installed. I use the browser. I
>>>> do not use the inspector. None the less, chromium declares that it
>>>> depends on chromium-inspector, which is thus installed. Recently
>>>> (around the time of heartbleed) there has come a security upgrade
>>>> for chromium-inspector. This upgrade conflicts (in some way, I
>>>> couldn't see how) with the existing version of chromium.
>
> A routine "aptitude -u" left me looking at the UI saying I had a
> conflict. I was obliged to put on hold an update to a package I don't
> want, despite this allegedly implicating a security problem for which I
> should upgrade. Which was scary, given that heartbleed had just hit the
> news.
>
> So no, aptitude was not happy to keep what it had. I had to uninstall a
> needed package and an unwanted package and then reinstall the needed
> package (which dragged the unwanted one back in) in order to get to the
> happy state that *I* can't distinguish from the original, but aptitude
> was indeed happy after that. However, it *wasn't* happy to begin with,
> which is exactly why I reported a bug.
There are several reasons why aptitude can complain about the state of
the package, like missing dependencies, or problems with packages that
it depends on (e.g. media codecs) being in an unconfigured state, or
marked for removal or to change to incompatible versions (or the same
recursively for all its dependencies), or needing a library that was
not available in testing at the time ("testing" lives up to its name,
sometimes).
Just uninstalling and installing triggers actions in other packages
that can solve the conflicts; it's not exactly/always a no-op. For
example, if dependency libdep1 was marked for removal, and you
uninstall just chromium, it marks libdep1 as "wanted by chromium, so
install/keep-installed/use-that-specific-version", and so solves the
conflict.
Basically, without knowing exactly what it complained about, there's
not much that can be done about this except speculate.
For example, when you saw chromium 34.0.1847.116-1~deb7u1 and marked
for installation (an upgrade of the version of the browser, but
changing the package to that targetted to the stable distribution),
chromium-inspector should have been marked to change to the same
version targetted for stable, 34.0.1847.116-1~deb7u1 (I believe that
they always require to upgrade in lock-step). Or the same with
34.0.1847.116-1 (without "~deb7u1"), if it was available in your
mirrors.
Lately, aptitude is very keen in telling you to remove packages rather
than do the sensible thing and telling you to upgrade to
chromium-inspector also version 34.0.1847.116-1~deb7u1. That's an
undesired behaviour and there are many bugs about that.
But if you manually mark both to stay in the same version, aptitude
should be happy about that -- at least, I haven't seen instances or
other bug reports complaining about this not working (also, another
way to do that explained below).
>> (If it pulled in new library dependencies or upgraded others, that could
>> have been what solved the previous conflicts).
>
> ... except that the prior conflict made no mention of any other such
> dependencies; and the uninstall-and-reinstall left me with *exactly the
> same* versions of all chromium packages that I'd had before. See the
> dpkg output sections of the original report.
As I said above, only the versions of chromium* are not enough, there
are many other things at play behind the scenes.
>> What I do not understand is what was improved after you reinstalled:
>>
>> - After you reinstalled, you could upgrade the browser to v 34 without
>> aptitude wanting to remove 'chromium'?
>>
>> - After you reinstalled, you could upgrade *other parts* of the distro
>> (not the browser), without aptitude wanting to remove the browser?
>
> After the uninstall-and-reinstall, aptitude no longer reported a
> conflict for chromium, which was still on version 33. I don't
> understand why it reported a conflict before; I don't understand why it
> was happy after; and it hadn't actually changed the version of the
> software it had previously grumbled about.
I think, as I said above, that in that case telling to aptitude to
keep v 33 of both and everything would have been fine, bugs aside.
(So, same result of what happened, just without reinstall).
>>>>In aptitude, I did see a version 34.0.1847.116-1~deb7u1 listed for
>>>>chromium; but attempting to mark the installed version for deletion and
>>>>this new version for installation does not work: it merely marks the
>>>>33.0... version to be kept installed, with the attendant conflict with
>>>>its own inspector.
>
> and that is about the view I get on the command-line after hitting
> return on the package, to view that package's details, then going to the
> bottom of the page, where it lists versions available. I'll have
> positioned the cursor on the 34 version and typed +, then been baffled
> at the 33 version getting selected. (I now understand its reason for
> not taking the 34 version as being the ~deb7 tag, where the system
> preferred the others, despite lower versions. I didn't understand that
> then, though.)
>
> (So yes, I did know that.)
If you want to upgrade to v34 but aptitude can't because of conflicts,
either sets a conflict or tries to do a remedial action (keeping the
current package at other version, to see if it fixes the problem), or
both, as in your case.
If you don't know about the feature, you can press 'e' when there are
conflicts, and then '.' and ',' to navigate forward and backward the
solutions offered, and press '!' if one of them satisfies you.
Usually the first solution is bad, but some of the rest are usually
acceptable, specially if there are few packages involved. One of the
solutions could have been: "keep these packages at the current
version: chomium, chromium-inspector".
Also as I said above, since a while ago aptitude is notoriously bad
when offering the solutions to conflicts (for example, keeping
chromium at v33 and reporting a conflict, rather than offering to
upgrade both). This should be improved, but it's not easy.
>> which in your case would have been probably 3: 33.0.1750.152-1
>> (currently installed), 34.0.1847.116-2 (available from testing) and
>> 34.0.1847.116-2~deb7u1 (available from stable, and probably what was
>> selected as candidate).
>
> I don't think I was being offered the 34 version from testing.
> I'd have mentioned it if I were.
>
> Maybe my mirrors weren't reporting those packages as available ?
> Out of date catalogues of available packages ? I just typed aptitude -u
> as usual and trusted the mirror to know what it was doing.
The version was released to unstable the 11th of April, with priority
"high". Usually, those trickle down to testing in 2 days, but if
there are problems with other libraries that it depends on (and it's
like 50 direct dependencies), it will not migrate until all of them
are ready. Sometimes, things take weeks or months to migrate, it's an
inevitable problem.
So maybe it simply was not available in testing at the time that you
updated. There are records about that, but I don't know how to find
the information quickly.
>> According to the info sent in the original report, you had both testing
>> and stable with the same priority, instead of testing with higher
>> priority.
>
> I have, incidentally, no idea how to set the priorities. I just had
> lines for both repositories in relevant sources.list.d/*.list files.
You can set priorities to the repositories, see "man apt_preferences",
so for example it prefers packages from testing but still uses from
stable if needed, or thigns like that.
In general, these things are tricky and testing is not always very
stable ;) By coincidence, I cannot upgrade ~250 packages right now,
most of them from the desktop, because of one of such transitions
going on right now...
Cheers.
--
Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
