Re: dist-upgrade strangeness: dependencies not deconfigured
Hi!
On Tue, 2014-03-25 at 22:38:45 -0700, Steve Langasek wrote:
> What you're showing here is a snapshot at some point in the middle of an
> upgrade, when texlive-common has been removed (because the package no longer
> exists, and the new texlive-base conflicts with it) and texlive-base has not
> yet been upgraded. It's legitimate to do this during an upgrade; in fact,
> normally the very next step is for apt to unpack the new version of
> texlive-base which had declared the Conflicts: with texlive-common. But
> something else stopped apt before it got that far.
Actually I'd say it's almost never legitimate for a frontend to do that.
> For the record, the removal of texlive-common without the deconfiguring of
> texlive-base is because apt will pass --force-depends to dpkg. It does this
> because in various scenarios, dpkg when left to its own devices can find
> itself in a catch-22 on dist-upgrades. So apt deliberately lets the
> dependencies be broken, with the expectation that it can fix them up again
> afterwards.
Which is wrong, no well-behaved frontend should need to use any force
option at all. The reason some frontends do is because they do not
tell dpkg exactly what kind of transaction they want to perform, so
dpkg is missing that information and migth find itself unable to
proceed. The correct way to do that would be by telling which packages
the frontend wants to be purged or removed via selections before
installing others so that dpkg can decide to remove them when needed
or convenient.
The much maligned dselect frontend has managed w/o any force option,
and unfortunately only somwhat recently I reasinged bug reports to apt
(#579790) and cupt (#575786 which I need to follow up on) to request
they switch to use selections too.
Thanks,
Guillem
Reply to: