Re: Can/should we have an efi/efi-any platform architecture?
On 11/12/14 18:08, Leif Lindholm wrote:
> The point is, when we add support for another architecture which
> supports UEFI, there are a number of packages that you will want to
> enable for that architecture.
I've occasionally wished we had a way to make a requiring package
conditionally built depending on availability of another package,
usually an interpreter that needs explicit porting. For instance:
* dbus should ideally Build-Depends: valgrind on precisely those
architectures where valgrind exists
* C# bindings should ideally be built on precisely those architectures
where mono exists
* Java bindings should ideally be built on precisely those architectures
where openjdk exists
At a source package granularity, you can fake it by having a (possibly
spurious) Build-Depends on the required package, which will put the
requiring package in BD-Uninstallable state (e.g.
https://buildd.debian.org/status/package.php?p=gtk-sharp3 explains why
gtk-sharp3 isn't built on mips, which doesn't have mono).
That doesn't work for individual binary packages unless you hard-code
architecture lists, though (e.g. a C library with an optional Java or C#
binding would need to hard-code the Java/C# architectures).
Perhaps this could be a build-profile?
Source: dbus
Build-Depends: ..., valgrind-dev <archfeature.valgrind>, ...
Source: libfoo
...
Package: libfoo-sharp
Architecture: any
Build-Profiles: <archfeature.mono>
Maybe we could even use package names as the features, so each feature
in the archfeature namespace is automatically said to be available iff
the package exists in apt? That covers the common "interpreter that
needs porting" case, although I don't know whether there's anything like
an efi-dev that could act as the "flag" for EFI architectures.
Other possible colours for this bike shed include pkgexists.valgrind,
with.valgrind, or (with the opposite sense) without.valgrind,
missing.valgrind.
S
Reply to: