Hello, On 12 December 2014 at 11:48, Johannes Schauer <j.scha...@email.de> wrote: > 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>, ... >
<snip> unlike Simon, I would tend to agree that we do want this. It's indeed not quite USE flags, but rather encoding per-arch default build dependencies. E.g. the way we encode default MPI per-arch implementation, default Java per-arch implementation and etc. However, this would imply to maintain default set of per-arch profiles somewhere, update them, and always use them. And secondly, I like that build-profiles can be used in a standard fashion to support non-free configurations of rebuilding main packages, aka <with-openssl>. But this use case is supportable with existing profile implementation. Thirdly I expect that we want default vendor profiles to exist. E.g. a lot of delta between ubuntu & debian can go away / incorporated in debian source packages if maintainers agree to merge something like "foo <!vendor-ubuntu>" (boost, e2fsprogs, zsh packages come to mind among others). -- Regards, Dimitri. -- 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/canbhlug_5yhspsbthrbhrm4eofzyepvap9md9wuvqexzty5...@mail.gmail.com
