Re: Can/should we have an efi/efi-any platform architecture?
Hi,
Quoting Simon McVittie (2014-12-11 21:49:55)
> 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).
Either "please don't add known-unused build dependencies as this will just make
the dependency graph bigger and life for bootstrappers harder" or, once jessie
is released, "if you feel you must, then add them with a <!stage1> (or similar
- not sure what would best apply here) build profiles restriction".
> 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>
Firstly, the build profile spec was revised during the bootstrap sprint in
Paris and what will end up in Jessie now does not have namespaces anymore. The
reasoning is fully explained in the sprint result email section 6.2:
https://lists.debian.org/debian-devel-announce/2014/08/msg00013.html
> 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.
Secondly, what you are expressing with:
valgrind-dev <archfeature.valgrind>
is that you do or do not depend on the package valgrind-dev depending on
whether or not "archfeature.valgrind" evaluates to true (however this is
resolved).
Build profiles are NOT meant for "tagging" purposes but for "conditional
selection of build dependencies". The disjunctive normal form expression of
build profiles does not make sense for "tagging" purposes as needed for this
use case ("archfeature.valgrind" is used like a "tag" that adds meaning to the
build dependency "valgrind-dev").
For this reason I don't think that build profiles will solve this problem.
cheers, josch
Reply to: