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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141217084500.ga16...@alf.mars
