Hi, Quoting Simon McVittie (2014-12-12 12:09:05) > Yes, but I think that's exactly what I want for dbus' use-case? I want > to build-depend on valgrind (I thought it was valgrind-dev, but it's > actually valgrind) on exactly those architectures to which valgrind has > been ported, so that the debug "flavour" of libdbus can have its > optional valgrind instrumentation on those architectures; but on > architectures to which valgrind has not yet been ported, dbus still > needs to produce working binaries. > > Some packages solve this by copying (a random snapshot of) the valgrind > headers into their source code, but I'd prefer to minimize the number of > embedded code copies. > > At the moment that's: > > Build-Depends: ..., valgrind [amd64 armhf i386 mips mipsel powerpc ppc64 > s390x], ... > > which is an inconvenient amount of hard-coding, and has led to one RC > bug already (when valgrind dropped support for armel). With build > profiles (which I'll reinstate in unstable when jessie becomes stable) > it would be something like: > > Build-Depends: ..., valgrind [amd64 armhf i386 mips mipsel powerpc ppc64 > s390x] <!stage1>, ... > > but I'd rather have > > Build-Depends: ..., valgrind <arch-where-valgrind-exists> <!stage1>, ... > > or whatever spelling.
okay. I get you now. Debian build profiles can express what USE flags do for Gentoo. What you probably want is: Build-Depends: ..., valgrind <!without-valgrind>, ... No need for the <!stage1> because you will probably have the "without-valgrind" build profile activated during a bootstrap unless you already have valgrind. Then buildds could set DEB_BUILD_PROFILES=without-valgrind on architectures without valgrind. Whether you call it "valgrind" or "without-valgrind" depends on what you want the default to be. In this regard, Debian build profiles work opposite to Gentoo USE flags. By default, no build profile is active which in Debian means: build everything with all features active. If no USE flag is enabled in Gentoo you get a very minimal build. Thus, if you want the default build to build *with* valgrind, then your profile should be named "without-valgrind" and only be set when you want to build without it (for example during bootstrapping or on architectures that don't have valgrind). > Similarly, db5.3 has > > Build-Depends: ..., default-jdk [!m68k], ... > (and other Java things on [!m68k]) > > and gdcm has > > Build-Depends: ..., cli-common-dev (>= 0.8~) [amd64 armel i386 > kfreebsd-amd64 kfreebsd-i386 powerpc ppc64 s390x], ... > (and other Mono things on those architectures) > > but there'd be no need for the Java and Mono maintainers to coordinate > these ad-hoc architecture lists with other maintainers via bugs like > #719842, #575138, #541612, #477855, #699379, #657779 if packages like > db5.3 and gdcm could instead say: > > Build-Depends: ..., default-jdk <arch-where-java-exists>, ... > Build-Depends: ..., cli-common-dev <arch-where-mono-exists>, ... It is entirely possible to add build profile names for a bunch of stuff like valgrind, java and mono (they would probably just be called "without-valgrind", "without-java" and "without-mono" - or s/without/no/). The question is, whether the Debian project wants to extend build profiles beyond it's current "limited" use for bootstrapping and cross building and thus make them more like Gentoo USE flags? This also means that if somebody builds the package locally on an architecture without valgrind, for example, then they must not forget to "without-valgrind" build profile or they will trigger a FTBFS. Thus it probably makes more sense to let the list of profiles that are active by default be stored somewhere on the system (which is also how it's done in Gentoo for USE flags). A good place for such a hypothetical list is probably dpkg. In that case, the buildds would also not need to do anything special when building. Should that be done, it probably also makes sense to add a facility to overwrite the default. In Gentoo they prefix a minus. In Debian, the most logical syntax would probably be the exclamation mark. So to enable valgrind on an architecture that doesn't have it would then be like: DEB_BUILD_PROFILES="!without-valgrind" dpkg-buildpackage or dpkg-buildpckage -P"!without-valgrind" You could then even go one step further and say: if dpkg stores a list of build profiles that are activated by default on an architecture, then the default list of active build profiles is not empty and there is no need to have a "without-valgrind" profile because the "valgrind" profile could be active by default on architectures with valgrind. This would make it quite a bit more readable and even more similar to Gentoo :P Thoughts? cheers, josch -- 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/20141212114840.15300.27739@hoothoot