On Sun, 9 Aug 2020 at 17:05, Adrian Bunk <b...@debian.org> wrote: > The pragmatic solution is to list the 3 architectures where julia > currently builds.
Okay, thanks for the hints, Adrian. That's what I'll do for now. > The software engineering solution would be a dependency package > julia-or-nothing that depends depending on the architecture either > on julia or nothing. This is a recurring problem, and seems slated to grow in severity as Debian tentacles inself into more heterogeneous environments and as software systems become larger and more complicated with more options. Machine learning systems in particular can be built against various sorts of hardware support libraries which phase in and out of fashion with shocking speed. So manually generating julia-if-available, and (thanks to Simon McVittie for the examples) valgrind-if-available, and libseccomp-if-available, etc, seems to scale poorly, and would be a lot of work. I suppose we could generate them automatically, like -dbg packages. Blech! They'd also pollute the archive. So let me step back and try to look at the problem a bit more globally. I understand what you're saying, and indeed trying to encode "Build-Depends-If-Available: foo" as "Build-Depends: foo | something" is a bad idea from the get-go. After all, foo can have three states on an architecture: installable, unavailable, or available-but-uninstallable-for-some-reason. And we want different behaviour in the three cases: build with it, build without it, or delay-building-until-installable. And we can't shoehorn those three things into the binary logic of "foo | something". On the other hand, the maintainer isn't really in the right position to figure out what architectures foo is available or should be installable on. The buildd's are the place where that information is really manifest. (And we might even make a stripped-down build, or a derived distribution without systemd, and want packages to adjust appropriately to that build environment as much as possible.) Making up a whole new control field, like Build-Depends-If-Available:, seems like overkill. But we already have a certain level of abstraction in architectures, e.g., we can say foo [linux] to get foo on systems running the linux kernel. How about we add this kind of thing as an abstract architecture. So one could write perhaps "Build-Depends: julia [has-julia]" to get julia iff a julia package exists. I think that would be pretty easy to implement (no installability check or backtracking; just check if a package by that name exists). It would also give more flexibility than a generic "Build-Depends: julia [IF-IT-EXISTS]" in case there are support packages necessary only if something else is available. Like "Build-Depends: chicken [has-chicken], swig [has-chicken]" to pull in swig if you're generating chicken bindings, which makes sense only if chicken is on that architecture. TLDR: suggest encoding as abstract architecture. Build-Depends: valgrind [has-valgrind], julia [has-julia]