Bug#684782: libgl1-nvidia-glx:amd64: Please add preferred package to "Recommends: nvidia-kernel-302.17"

[Andreas Beckmann]

On 2012-08-13 21:29, Ralf Jung wrote:
> currently, doing "sudo aptitude install libgl1-nvidia-glx" on a new system
> pulls in loads of unwanted stuff: Namely, the rt flavour of the linux kernel is

the -rt- prebuilt modules will go away as the ABI is not considered
stable (and would require a rebuild for each kernel update, not only for
each kernel ABI bump)

> installed. I assume this is because of the Recommends: for the virtual package
> nvidia-kernel-302.17, which does not give any preference, and aptitude doing a
> strange choice here. When depending on a virtual package, it is common to
> provide the preferred "provider" of this virtual package as first alternative
> ("Recommends: nvidia-kernel-dkms | nvidia-kernel-302.17"): apt-get and aptitude
> will prefer that package, but not install it if something else providing this
> package is already installed.
> The same holds for the dependency on nvidia-kernel-302.17 in nvidia-glx.

Recommends: nvidia-kernel-dkms | nvidia-kernel-${nvidia:Version}

This does not work, as *any* version of -dkms will satisfy this, not
neccessarily the one providing -${nvidia:Version}, so we would need to
use rather ugly versioned dependencies:

Recommends: nvidia-kernel-dkms (>= ${nvidia:Version}) |
nvidia-kernel-${nvidia:Version}, nvidia-kernel-dkms (<<
${nvidia:Version}.0) | nvidia-kernel-${nvidia:Version}
(and actually, we need even some more variables in there ...)

Hmm, we could use (= ${binary:Version})

> While you are at it, please consider whether it is appropriate to make nvidia-
> kernel-dkms "Multi-Arch: foreign", since currently resolving the dependencies
> of libgl1-nvidia-glx:i386 on an amd64 system tries to pull in nvidia-kernel-
> dkms:i386, which of course does not work.

ACK. pending.


Andreas