Hi :) Quoting Guillem Jover (2014-03-07 22:34:15) > On Fri, 2014-03-07 at 15:57:53 +0100, Johannes Schauer wrote: > > The problem might lie in the fact that I do not understand how "profiles > > the binary package gets produced for" is different from "profiles the > > binary package supports or can be built with". > > Ok, two scenarios. First one, you have a source producing multiple > binary packages, one of which contains only an ldap plugin. If the > package honours a build profile that restricts on ldap then that > package would not get produced at all, this is the common case you > find in a bootstrapping scenario for example. The second one, would > be a source package that produces for example a foo-plugins binary > package containing say ldap and mysql plugins, and if a restriction > on ldap is requested then that binary will end up only containing the > mysql plugin, so that package supports and can be built with such > profile.
Ah I see. Yes the Build-Profiles field in this context was meant to mean "does or does not build" and not "produces a somehow different package when profile activated". The idea was that when a build profile is activated, the binary packages which are produced in the end should not provide any different functionality than under a full build. Otherwise a binary package depending on such a profile-built binary package might find its runtime dependency not fulfilled in practice. This would also make it impossible for automated dependency resolving tools like botch (and dose3) to find a correct bootstrap order. Such tools have to be able to rely on the fact that when a profile built source package creates a binary package A then this binary package provides all functionality it would with a full build. If this can't be achieved then we can't automate bootstrapping anymore and must go back to doing things by hand. This would defeat one big purpose of introducing build profiles as machine readable meta data instead of hacks and comments in the packaging code. So in practice this might mean that binary packages must be split to ensure this property. In other cases (for example for self-cycles) it might mean that a temporary binary package with a different name is created in stage1 so that it can fulfill the build dependencies of stage2 which can then in turn build the full binary package. Like this: Source: foo-compiler Build-Depends: foo-compiler <!profile.stage1 !profile.stage2>, foo-compiler-stage1 <profile.stage2> Package: foo-compiler Build-Profiles: !stage1 Package: foo-compiler-stage1 Build-Profiles: stage1 The source package would be compiled in stage1 first to produce foo-compiler-stage1 which is needed to fulfill the build dependencies for stage2 which produces the final foo-compiler. I dont see though how it can be enforced in practice that binary packages produced with a build profile activated are equal to binary packages for full builds without reproducible builds. Following this advice seems very cumbersome and it surely impacts on good packaging practices but if we consider that only around 60 source packages have to be changed to make all of Debian bootstrappable and that it would allow full automation of the bootstrapping process, then it maybe does not sound too bad anymore. The only other way I see is to introduce a mechanism to explicitly depend on either the binary package produced with a full build or with a specific profile. But that seems overkill if the problem can be solved as outlined above. It sounds especially like overkill if one considers that bootstrapping is only the exception. I updated the wiki page accordingly. > > In the spec [1] it says: "In debian/control binary package stanzas, the > > content of the Build-Profiles field specifies the (unordered) list of build > > profiles for which that binary package does or does not build.". So if a > > package in debian/control says: > > > > Build-Profiles: stage1 > > > > then that binary package would only build when stage1 is active. If it says: > > > > Build-Profiles: !stage1 > > > > then that binary package would build in all cases except when stage1 is > > active. > > This is what debhelper recently implemented. > > Yeah, this is clearer now, I seem to remember a different wording when > I saw this initially, probably in the mailing list, but I might be > misremembering. I still wanted to make sure. > > > Do you find this problematic? > > Not really, it matches the Architecture field, in that it describes > in a descriptive way when the package should be produced or not. And > I find this makes more sense than what I had understood initially. Good. > But this ties with the desire to know when those build profiles apply from > the Sources/Packages files, which applies to the two scenarios described > above. Right now the information which binary packages do or do not build for which build profile is restricted to debian/control. Coming back to my original mail: what do you see as the best way to propagate this information into the Packages/Sources files? Thank you! cheers, josch -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140308001306.2428.90314@hoothoot