Source: nvidia-graphics-drivers
Version: 525.147.05-6
Severity: normal

From time to time the version of nvidia-driver in experimental is far
ahead of the current version in unstable. It's often desirable to
install it to see if the new version fixes particular problems.

The problem is that there are many different packages generated for nvidia-graphics-drivers. Ideally the same version would want to be
installed for all of them, including the cuda or opencl components.
This means to upgrade to the new version in experimental, one has to individually select every single nvidia component. There's more than
20 of them, it's a bit of effort.

Conversely, if the experimental version becomes stale, it does not get automatically updated. One might need to step back to the nvidia
version in unstable if the experimental version no longer confirms to
package standards, or to get automatic updating going forward. Or
there might be a new version in experimental, which is not
automatically updated. Either way, one again has to select every
single component package and mark it explicitly for downgrade or
upgrade.

It would be much easier to switch between versions in unstable and experimental, or upgrade from experimental, if there were a dummy
dependency package that depends on all the manifold nvidia component
packages for the given version. It could be called nvidia-driver-all,
for instance. Then only the one package needs to be marked for
upgrade (or downgrade) and will bring in all the others.

Can it be done?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 14/02/2024 00.37, Drew Parsons wrote:

It would be much easier to switch between versions in unstable and experimental, or upgrade from experimental, if there were a dummy
dependency package that depends on all the manifold nvidia component
packages for the given version. It could be called nvidia-driver-all,
for instance. Then only the one package needs to be marked for
upgrade (or downgrade) and will bring in all the others.

Can it be done?

Yes. I'd probably call it nvidia-driver-full (as in texlive-full) since
-all could be mistaken as 'installs all (supported) driver series'.
And you would want hard Depends and no Recommends ?
Is there anything that should be excluded?
Are there any binary packages from different source packages that should
be included as well? Mainly thinking about bits that are included in the
.run file but since source is available, we build it from source
instead. nvidia-settings, nvidia-xconfig, nvidia-persistenced?

Andreas

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-02-15 14:20, Andreas Beckmann wrote:

On 14/02/2024 00.37, Drew Parsons wrote:

It would be much easier to switch between versions in unstable and
experimental, or upgrade from experimental, if there were a dummy
dependency package that depends on all the manifold nvidia component
packages for the given version. It could be called nvidia-driver-all,
for instance. Then only the one package needs to be marked for
upgrade (or downgrade) and will bring in all the others.

Can it be done?

Yes. I'd probably call it nvidia-driver-full (as in texlive-full)
since -all could be mistaken as 'installs all (supported) driver
series'.

That sounds sensible.

And you would want hard Depends and no Recommends ?

I think it would need to be a hard Depends. Otherwise a Recommends
would only activate once the first time the dependency package is
installed. Since it's not mandatory, it wouldn't succeed in maintaining consistent versions when upgrading or downgrading. A Recommends (=)
together with a Conflicts would not work since the versioned
dependencies don't have a != operator to use with Conflicts.

Is there anything that should be excluded?

Only question I can think of for exclusion is whether cuda should be
included. For sure not everyone who would want the driver upgrade would necessarily want cuda as well, in the sense that they simply aren't
using cuda. So one option is make two dependency packages,
nvidia-driver-full for the drivers without cuda, and nvidia-cuda-full
(or just cuda-full) for the cuda components. I guess nvidia-opencl-icd (nvidia-opencl-common) might belong in nvidia-driver-full since it's
kind of a "conflict of interest" to put it with cuda.

Two dependency packages like this would meet requirements fine I think.
But if it's too much trouble to split them that way and you'd prefer one dependency package, then I'd suggest including the cuda packages in it.

Are there any binary packages from different source packages that
should be included as well? Mainly thinking about bits that are
included in the .run file but since source is available, we build it
from source instead. nvidia-settings, nvidia-xconfig,
nvidia-persistenced?

I don't think the dependency package would need to set external
dependencies. The actual binary packages would bring these in as needed
in their own Dependencies. The dependency package would just need to
make sure all the nvidia package versions remain in step.

Drew

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)