regarding nvidia-cudnn

[M. Zhou]

On Thu, 2023-06-29 at 17:52 +0200, Andreas Beckmann wrote:
> Hi Lumin,
> 
> I've pushed a few fixes for nvidia-cudnn.
> 
> There is no need for a fake library, it's sufficient to ship the 
> (dangling) SONAME symlink in order to make dpkg-shlibdeps work for 
> rdepends. Verified by an autopkgtest.
> (If the fake library file gets replaced by the real one (or a symlink in 
> this case), this raises a debsums error in piuparts.)
> Would we need these symlinks for the other libraries as well?

Thanks! I always wanted to get a nicer solution for the dependency
resolving issue. Now you made it!

We only need the symlink for libcudnn.so.8 and libcudnn.so.
Applications will be linked against the dispatch library libcudnn.so.8,
instead of sublibraries.

> While looking at the package, some questions came up:
> 
> The generic virtual package name would be libcudnn-dev. Why isn't that 
> being provided (with a version)?

The current virtual package name is libcudnn.so, which is a more general
-dev package name. Since it is an all-in-one package (dev+runtime),
I don't see the necessity to provide multiple virtual packages.

> Why is there a dependency on nvidia-cuda-toolkit(-gcc)? I can only find 
> inclusion of cuda_runtime.h and libraries linked against 
> libcublas.so.11/libcublasLt.so.11. Therefore a (versioned) dependency on
>      nvidia-cuda-dev (>= 11), nvidia-cuda-dev (<< 12)
> should be sufficient. It needs to be versioned that way since you want 
> it to pull in libcublas11 etc.
> (If some project using cudnn wants to build with nvcc, it needs B-D on 
> nvidia-cuda-toolkit-gcc.)

It depends on cuda toolkit because cudnn runtime needs the cuda run
time libraries. But there is not a cuda-toolkit-runtime binary. So I simply
included the full cuda kit as dependency.

BTW, We can recommend nvidia-cuda-toolkit-gcc, since this is also a -dev
package.

> Why does the nvidia-cudnn package have Pre-Depends but no preinst 
> script? I think they can all be moved to regular Depends.

I don't remember why I use Pre-Depends here, but I must had a reason.
Most likely it is due to sbuild failure due to installation order when
preparing the build environment for pytorch-cuda.
Please leave it there for now, and I'll move it to the
usual depends if I'm sure it does not break the PyTorch build.

> Downloading with wget uses this command line option:
>    --hsts-file=/tmp/wget-hsts
> Please don't use a deterministic file, but either drop it or use 
> /dev/null (if possible) or a temporary file from mktemp.

Will make the improvement in the next release.

> And most importantly: As an installer package, you need to verify the 
> integrity of the downloaded file, especially if you want it to use it as 
> a build dependency which shall install automatically.
> If the downloaded file does not match a predefined checksum, abort 
> before extracting it.
> 
> An example installer package with verification:
> https://salsa.debian.org/debian/b43-fwcutter/-/blob/master/debian/firmware-b43-installer.postinst

Great! Will implement in the next release.

Thank you!