Re: Why is ggml not migrating?
Hi Adrian,
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.
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
(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.
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.
> 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.
> On Mon, Dec 08, 2025 at 08:35:42PM +0100, Christian Kastner wrote:
>> people usually maintained an entire separate
>> fork of the source (where upstream is even binary-identical), which is
>> cumbersome, less discoverable, and adds maintenance burden all around.
>> ...
>
> Regarding "cumbersome" and "maintenance burden", you are anyway doing
> two uploads every time you update ggml. Something like the script you
> used can just automate building src:ggml-cuda and then upload both.
True. But on the other hand, two source packages means they can get out
of sync in other areas, or cause extra work there.
Think of the NEW queue for example, when either src:ggml adds a new
backend, or the library bumps the SOVER.
(Having src:ggml-cuda stuck in NEW was actually the main reason why I
looked into the build profile, because the idea of a separate review
seemed entirely pointless busy work all around.)
> This also removes the cumbersome maintenance burden for others to be
> aware that your package is doing something very special and unexpected.
>
> Regarding "discoverable", the profile approach is far worse.
> People doing QA are doing archive rebuilds also for contrib and non-free,
> which won't cover binary packages hidden behind a profile.
An additional argument would be eg: the Debian NVIDIA Team wanting to
test some new CUDA release, and rebuilding all reverse dependencies.
A counter-argument would be a users looking at ggml's tracker and
expecting to see the libggml0-backend-cuda among the other backends.
> 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.
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.
But infra/tooling/practices trump my personal intuition, of course.
Best,
Christian
PS: Unless anyone objects, I'd like to proceed with the current approach
in unstable in the short-term, simply because it's the status quo to get
the CUDA backend. A switch back to a src:ggml-cuda would require a bit
of planning, because of NEW.
Reply to: