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.
