+++ Matthias Klose [2013-01-16 21:09 +0100]: > Am 16.01.2013 17:26, schrieb Johannes Schauer: > > On Wed, Jan 16, 2013 at 04:00:15PM +0100, Matthias Klose wrote: > >> > >> So it does make sense to build with two profiles like stage1 & check.
Yes. I can think of situations where being able to specify more than one profile at a time would be useful/flexible. stage1 & cross for example. I'd like to enable this if it doesn't make things too complicated. > > Your first example indeed demonstrates why multiple profiles are useful > > to be enabled at once. > > > > The second example can be accomplished with only one profile by marking > > all dependencies that are not being needed by a "nocheck" profile as not > > being needed by the "stage1" profile as well. > > > > So instead of: > > > > Build-Depends: foo <!stage1>, bar <!nocheck> > > > > and then needing two profiles at the same time, one could have: > > > > Build-Depends: foo <!stage1>, bar <!nocheck !stage1> > > > > Though I agree that the first option looks more maintainable. > > and I would assume that it better documents the intention. It maybe could be > used for a (native) test rebuild on a slow architecture, where you wouldn't do > that otherwise. For this case I don't want to have a package built with > reduced > functionality. Makes sense. > > There is also the idea of a "nodocs" profile which would work like > > DEB_BUILD_OPTIONS=nodocs. > > This seems to be less important, because these b-d's most likely end up b-d-i. There is potentially some overlap between DEB_BUILD_OPTIONS and DEB_BUILD_PROFILES. Indeed implementing them as DEB_BUILD_OPTIONS=profile=foo was in the spec at one point but we moved away from that. My feeling for the best way to think about this is that DEB_BUILD_OPTIONS are for things that don't change the dependencies (optimisation options, parallelisation options, most checks). DEB_BUILD_PROFILES are for things that do have dependency implications (bootstrap builds, embedded builds, check-only build-deps, binaries not produced). > Side question: if a package offers a --disable-docs configure option, is > there a > good way to enable it for arch only builds? Shouldn't this be done in the rules file for binary-arch/binary-indep targets? > did somebody make an analysis for what stage1 and stage2 are currently used > for? Not a formal analysis, and having a done a few I suspect you have as good an idea as anyone. I've found: Removing language bindings, removing optinal library deps (selinux for eglibc for example, ldap for gnupg or krb5), building without gui components when some fairly low-level package also has a gui-tool that brings in a pile more build-deps. > I would like to see more descriptive profiles, so I can break down these > profiles ... For packages within a buildd chroot, I see > > - nobindings -- disabling bindings for various interpreters/languages. > (could be something for DEB_BUILD_OPTIONS too, like nobindings=python,tcl) > > - no ... gobject-introspection, building udev without gobject-introspection > and libgirepository1.0-dev. > > Even if there are a few more, I like it better to make the profiles more > granular, and then letting the people doing a bootstrap decide what to include > in a stage1 or stage2 build. I can see some logic to this, and ultimately profiles _could_ be used for anything like this. Packagers are best-placed to know which aspects of their software are logically optional. But this could get out of hand with a very long list in the build-deps line, so we should resist going too crazy. libdose can cope with an arbitrary set of profiles, and work out which ones provide linearisable builds, so maybe there is no actual need for regularised names (stage1, stage2), so long as available profiles are discoverable (as ijw mentioned - I agree that would be wise). I'm not sure how this might work with generating version numbers so profiled builds supercede each other correctly in automated uploads to a bootstrap repo. It's easy with 'stage1, stage2'. Tools would have to get smarter with arbitrary names. But we can probably make it work with a bit of thought. And it will work 'manually' without this (but it's very annoying fighting reprepro all the time). One thing that should come out of this work is recomendations for packagers on what profiles are available/recommended/supported by tools. We can use the mechansim as much/little as seems sensible. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130117031831.gs5...@stoneboat.aleph1.co.uk