Re: Build-Depends-If-Available
On Sun, 9 Aug 2020 at 17:05, Adrian Bunk <bunk@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]
Reply to: