An interesting strategy for certain CUDA builds

[Christian Kastner <ckk@debian.org>]

Hi,

The last component of ggml [1] was recently accepted with an interesting
strategy I'd like to share: it contains the CUDA backend build, without
requiring a separate ggml-cuda source package.

The way this works is simply through a build profile 'pkg.ggml.cuda'
that is inactive by default. Therefore, it is skipped on the official
buildds.

After a regular source-only upload of ggml, I do a build with that
profile, which builds the CUDA backend exclusively when enabled, and
then upload the resulting binaries:

  $ sbuild \
	--extra-repository 'deb http://deb.debian.org/debian unstable contrib non-free'
	--profiles pkg.ggml.cuda \
	-d unstable
	...

The nice thing about is not just that it reduces the work in preparing
uploads, but on the tracker page [2], the CUDA binaries are seen
together with the other binaries of the same package, aiding
discoverability. And they share the same changelog, etc.

The downside is that it requires a bit of extra work to set up, some of
which is slightly tricky. Also, this only works for packages that build
loadable backends, or plugins, via dlopen().

Also, this obviously only works for packages which go into contrib/,
because the source must be DFSG-free.

Best,
Christian

[1]: There is a mismatch from when I first introduced the strategy, in
     August, and the acceptance, last week, because when I uploaded it
     to NEW, I overlooked the fact that the CUDA backend needs a
     separate build and upload, even if built from the same source.
     Obvious in hindsight.

[2]: https://tracker.debian.org/pkg/ggml