Re: propagating the value of the build-profiles field to Packages and Sources files
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
Reply to: