Re: missing libgl1-mesa-dri in upgrades

[David Kalnischkies <kalnischkies@gmail.com>]

On Mon, Apr 1, 2013 at 11:16 PM, Daniel Pocock <daniel@pocock.com.au> wrote:
> On 01/04/13 22:04, John Paul Adrian Glaubitz wrote:
>> On 04/01/2013 09:59 PM, Daniel Pocock wrote:
>>> Agreed, but that doesn't complete the picture, as libgl1-mesa-glx
>>> doesn't depend on libgl1-mesa-dri:
>>>
>>> $ apt-cache depends libgl1-mesa-glx
>>>    ...
>>>      Recommends: libgl1-mesa-dri
>>>
>>
>> Well, "Recommends" are installed by default, aren't they? However, I'm
>
> Not during upgrade or dist-upgrade operations.  This is specifically an
> upgrading issue.  From man apt-get:
>
> "  upgrade:
>  ...  under no circumstances are currently installed packages removed,
> or packages not already installed retrieved and installed."

Correct for apt/squeeze, partly-wrong for apt/wheezy (since 0.8.15.3).
A package requiring a new recommends which is in a non-broken policy state
previously will be held back just like other packages requiring a new depends
in apt/wheezy.
In apt/squeeze the policy will break, which you could fix with
"apt-get install --fix-policy", but that is going to fix ALL recommends.

We are going to be "fine" in this regard as many packages have a new
dependency in a new release (upgrade is mostly for between releases).
In this case it is at least "multiarch-support".


> "dist-upgrade:
> ... intelligently handles changing dependencies with new versions of
> packages"

dist-upgrade on the other hand installs new recommends since the introduction
of recommends. Keyword is "new": If you had recommends disabled previously
and/or removed a recommends apt will not install this recommendation again.
(It compares the recommends list of the old version with the new version and
 only uninstalled recommends present in the new, but not in the old version
 are marked for installation).
Of course, if the recommends isn't installable you will still get a solution
which doesn't include this recommends which will be displayed as usual.
You have to install it later by hand then as it now an old recommends …
(In stable, uninstallability shouldn't happen though)

I guess the confusion comes from the word "dependencies":
In APT namespace "dependency" means any relation which is allowed;
not just a "Depends".

So the sentence should be read as "… handles changing Pre-Depends, Depends,
Conflicts, Breaks, Replaces, Provides, Recommends (if enabled, default yes)
and Suggests (if enabled, default no) with new versions …"
(for the sake of completion: Enhances are not handled)
It's just that a user shouldn't really be required to know what those are.

(if you digg deaper [usually in non-user facing texts] you will come across
 "hard", "important", "soft", "negative" and "positive" dependencies to
 complete the confusion. I will leave it as an exercise for now which subsets
 are meant with those adjectives)


Best regards

David Kalnischkies