[Aptitude-devel] Bug#745425: aptitude: dependency handling jammed on chromium upgrade

[Edward Welbourne]

> To try to see if we are on the same page, this is what I understood so far:
>
> - That at the time, aptitude was happy to keep v 33 of the browser
>   packages, it didn't want to remove it before you gave instructions to
>   update other packages (how, btw?  Command line "aptitude
>   safe-upgrade"?  "aptitude full-upgrade"?  interactive curses
>   interface, marking all upgradable packages to upgrade?).

No, not really.  As I said:

>>> 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.

> - The problem was caused when you asked to upgrade: at that point, it
>   only allowed upgrading by wanting to remove "chromium-browser" (or at
>   least, offering that as the first alternative to allow the upgrade).

I ran "aptitude -u", to get my package lists up to date.  After that, I
had aptitude reporting a conflict.  It wanted to upgrade
chromium-inspector (which I don't use) and the upgrade required that I
uninstall chromium-browser (which I do use).  I had every reason to
suppose that I would be unable to reinstall it - since it was dragging
in an unwanted package that conflicted with it.  I put the upgrade on
hold - hoping it was just some package metadata goof-up that would be
fixed soon enough - and came back to it a few days later.  As it wasn't
fixed, I set about documenting prior state and aptitude's behaviour as I
tried the only thing I could think of that might get me out of the
problem.

> Then I assume when you reinstalled ("Eventually, I uninstalled both
> packages, then installed chromium afresh"), only 'chromium' and
> 'chromium-inspector' were involved, or did it also remove / install /
> upgrade other packages?

No, it put back the inspector automagically - as I said in the report:

>>>Eventually, I uninstalled both packages, then installed chromium afresh.
>>>The above dpkg command now reports <quote>
>>>
>>>Desired=Unknown/Install/Remove/Purge/Hold
>>>| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
>>>|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
>>>||/ Name                     Version           Architecture      Description
>>>+++-========================-=================-=================-=====================================================
>>>ii  chromium                 33.0.1750.152-1   amd64             Chromium web browser
>>>un  chromium-codecs-ffmpeg   <none>            <none>            (no description available)
>>>un  chromium-codecs-ffmpeg-e <none>            <none>            (no description available)
>>>ii  chromium-inspector       33.0.1750.152-1   all               page inspector for the Chromium browser

I uninstalled both, then told aptitude to install the one I wanted.  It
duly reinstalled the one I didn't want, too.  Which is why my report
began with a grumble about the misguided package dependencies.  I get
that that's the chromium maintainer's bug, not yours, of course.

> (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.

> 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.

> That  was in the curses interface, or the command line?

This was on the console from a command line.  (Which I naively suppose
is in fact a curses interface, since curses is an API for talking to
VT100-like things; and ldd does indeed report aptitude as linked against
libcurses.so.5.)  There was no X window anything involved, not even via
a curses-X-compatibility library.

> You probably know this, but just in case... In the initial / main view
> and curses, one can only see two versions (current and candidate).  If
> you go to the package and press "v" (or "enter" to go to the package
> info screen, then go to the bottom) it will show all available versions,

In the original report, I mentioned

>>>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.)

> 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.

> 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.

	Eddy.