On 12/12/14 11:48, Johannes Schauer wrote: > Debian build profiles can express what USE flags do for Gentoo.
They're not quite the same purpose, because we build one binary package per architecture, not one set of installed binaries per installation. Continuing the db5.3 example, we should continue to use binary-package splitting to handle sysadmin preferences like "my x86 system is a minimal server and I don't want Java" - but what I'm looking for a way to handle portability constraints like "I would want Java to be available if it existed, but it isn't portable to m68k". (Or, perhaps more realistically, mono is currently unavailable on mips, arm64 and ppc64el.) AIUI, on Gentoo, USE flags have to serve both purposes. > 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). What I was trying to suggest is that build infrastructure could look at the set of Build-Profiles declared in the .dsc, look for profiles matching some pattern (let's say without-*), and automatically enable without-foo for each foo that is mentioned in Build-Profiles but does not exist in apt's Packages file. That would immediately provide without-default-jre (for Java bindings - we don't have an arch:any 'java' package), without-mono, and without-valgrind... > 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 ... and avoid that problem. S -- 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/548ae2f2.8070...@debian.org