On Tue, Dec 09, 2025 at 11:04:17AM +0100, Christian Kastner wrote: > Hi Adrian,
Hi Christian, > let me start by re-iterating that I'd be on board to switching back to a > src:ggml-cuda if this cooperates more with our tooling/infra/practices. > > My counter-arguments below aim only to ensure that we cover all the > bases. It's not even that much about ggml -- I think we're touching an > interesting problem in general here. nothing here is new, packages like starpu and slurm-wlm already have additional -contrib source packages for Nvidia reasons. > On 2025-12-09 07:04, Adrian Bunk wrote: > > I am not a member of the RT, but having binaries from the same source > > package built in two different ways in the archive sounds just wrong. > > The build profile argument hinges on three ideas, namely that > > (1) only main is part of Debian proper, and ggml has exactly one > policy-conform process for ggml in main, so all good there > > (2) because the other binary goes into contrib, a second build process > is needed anyway It's not relevant here, but the actual reason is the build dependency that is not in main. Otherwise building main+contrib from the same source package works fine (e.g. src:openh264). > (3) because of the nature of this contrib package, this second build > process will always be manual. > > Because of (3), I assumed that the same source/two different builds > approach wouldn't be much of an issue. > > A contributor will always have to read debian/README.Source to update > the package, and I didn't see much difference in whether this doc says > "run debian/cudabuild.sh, then build" or "build with build profile". > > > I am someone who does sometimes over 100 NMUs for RC bugs in a single > > week - after an NMU the CUDA packages would just silently disappear? > > That might actually be the best outcome, as a consequence of (3) above. > > Because if you NMU src:ggml, you'd also need to NMU src:ggml-cuda. And > the only way you can NMU src:ggml-cuda is via debian/README.Source, and > whether that points to debian/cudabuild.sh or --profiles='pkg.ggml.cuda' > is just a detail. This is not true. ~99% of my NMUs for RC bugs do not touch the upstream tarball, it's either editing debian/rules or adding to debian/patches. Like I did a lot of "FTBFS with CMake 4" fixing recently, which most of the time was just either bumping the version in cmake_minimum_required or doing the same in debian/rules with -DCMAKE_POLICY_VERSION_MINIMUM=3.5 >... > > The security tracker would also not notice if there are binary packages > > that have not been rebuilt, leaving users vulnerable to a fixed CVE. > > On the other hand, two sources packages mean that the trackers for each > need to be maintained separately. >... Better maintaining them separately than giving users a false sense of security. contrib and non-free are not supported by the Security team, which makes it not unlikely that only the packages in main will be fixed as part of a DSA. You as maintainer can provide security fixes for contrib, but this is not something our users can rely on. >... > Assuming the NMU is for something bad, it might be better to have the > CUDA backend removed instead of stale. > > > A variant of that would be if someone other than you prepares a security > > update for stable. > > Here, I'd definitely prefer removal if the second build doesn't happen. During a DSA no one might notice the hidden CUDA packages, I am not sure anything would flag before the next point release day that these hidden packages are missing. And again, for something like CVE-2025-53630 a new patch would get added to debian/patches and no one reads debian/README.Source in that case. Also, if you would prefer removal when only the packages in main get a security fix, this implies that the CUDA packages should not be in stable releases at all. > > A similar issue is also present for downstream distributions like > > Ubuntu or Raspbian, that might have different rules regarding what > > is autobuildable for them. > > > A successful "dpkg-buildpackage -b" producing all binary packages is > > a pretty fundamental assumption in various places. > > I agree that these are good counter-arguments to assumption (3) above. > > The simple local rebuild alone was already a concern to me. But as per > (1) above, the result in main is correct and policy-conform, so I didn't > see a problem there. And I felt that contrib/non-free, by their nature, > offered more lee-way. (1) is not true. Policy 2.2.3. says that packages in contrib must meet all policy requirements. >... > As a final argument in favor build profiles, it felt to me like it was > the intuitively correct approach to handle optional plugins, as is the > case here with ggml. Note that ggml has a build profile to disable HIP > builds (for AMD GPUs) because that takes substantial resources, and > would be irrelevant in an NVIDIA GPU-based context. Profiles are fine for enabling developers/users to build a package in a different configuration, but they shouldn't be used in the archive. > But infra/tooling/practices trump my personal intuition, of course. > > Best, > Christian >... cu Adrian
