Re: Can/should we have an efi/efi-any platform architecture?

[Helmut Grohne <helmut@subdivi.de>]

On Thu, Dec 11, 2014 at 08:49:55PM +0000, Simon McVittie wrote:
> 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

There is a slightly ugly technique, that achieves what you want without
build profiles or any recently added functionality.

Considering the valgrind example:
 * Have valgrind Provides: optional-valgrind
 * Add a new binary package no-valgrind to the valgrind source package.
   It also Provides: optional-valgrind. This new package is only built
   for architectures where valgrind is not built.

Now dbus can Build-Depends: optional-valgrind.

As the architecture field does not allow negated architectures, a clear
downside is that now you have to maintain two architecture sets for
valgrind. So when e.g. or1k comes along you will have to add it to
either valgrind or no-valgrind.

Still the tradeoff seems to be good as soon as optional-valgrind
collects a handful reverse dependencies.

What do you think?

Helmut