Bug#1035024: unblock: nvidia-cudnn/8.7.0.84~cuda11.8+1 (pre-approval)
On Sun, 2023-05-07 at 22:03 +0200, Paul Gevers wrote:
> Control: tags -1 moreinfo
>
> Hi Mo,
>
> On 27-04-2023 21:31, M. Zhou wrote:
> > So, generally updating the package is simply to update the binary
> > tarball URL in the script, along with the exact version number,
> > which is very trivial.
>
> So why didn't you ask for only this?
I thought about this choice. This package is hardly useful without
the the fake library (for fixing dh_shlibdeps resolving), because it
cannot serve as a component in the dependency chain for its future
reverse dependencies. Even if the current testing package entered
the next stable, it is still hardly useful.
So if this is not going to be approved, I would prefer to get it removed
from testing and prepare for the stable backports instead.
> > 4. debconf template default choice is changed to "I Agree".
> > This package is in non-free section. Only by setting the debconf default choice
> > to "I Agree", can we correctly build pytorch-cuda in sbuild without the cuDNN
> > libraries not downloaded but the bin:nvidia-cudnn package installed.
>
> Are we legally allowed to do this? If so, why even ask the question?
According to the upstream license and the package content, the URL points
to a distributable tarball depending on the user's agreement.
The debconf questions shows the full license texts and asks the
user whether to accept the terms. These terms, was deemed problematic
by ftp-masters if we directly upload the binary blobs into the archive.
At least, building the reverse dependency pytorch-cuda via sbuild, where
the binary blobs will be pulled and linked against, is legal according to
the license. Uploading the binary form of pytorch-cuda is ok as well.
Other binary distributions like ArchLinux, Anaconda, and even PyTorch
upstream have been redistributing the cuDNN binaries for years though.
Although I hate dealing with annoying non-free license texts, I think
it not safe to remove the debconf question prompt, because the license
seems to pose even more restrictions than its dependency CUDA devkit.
> Paul
> PS wasn't an autopkgtest feasible such that this didn't need to be on
> our radar? (too late for that now, but still)
It looks like I have to refresh my memory, I thought autopkgtest won't
be run for non-free packages. Writing the test scripts are easy, but I think
that's not needed if I can get a manual removal or refusal.
I checked the license, some simple test scripts for testing the downloader
script, and do some testing compilation / linking will not violate the license.
Will add them in the future.
Both would work for me. I'm ok with stable backports. Afterall pytorch-cuda
will only be available through backports.
P.S.
I really hate dealing with this package with a complicated end user
agreement. It leads to my years long procrastination for the pytorch-cuda
preparation. But, I was still forced to get it done solely due to the
nvidia monopoly if we want a mature and high-performance version
of pytorch. That said, the debian-ai@l.d.o team is diligently working
on AMD's open-source ROCm, which provides alternatives for nvidia
CUDA and cuDNN. When the ROCm stack is ready in our archive, I
want to gradually give up the cuda branch and the corresponding
effort -- pytorch-rocm can enter main, while pytorch-cuda can never.
Reply to: