Re: propagating the value of the build-profiles field to Packages and Sources files
Hi!
[ Sorry, have been traveling. ]
On Sat, 2014-03-08 at 01:13:06 +0100, Johannes Schauer wrote:
> Quoting Guillem Jover (2014-03-07 22:34:15)
> > 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".
Ok.
> 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.
Right, something I had listed in the original proposal [B] (§4), which I
think should be followed in Debian, but I could see external parties
wanting to diverge on this, though.
[B] <http://www.hadrons.org/~guillem/debian/docs/embedded.proposal>
> 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:
[…]
>
> 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.
Sure. This would end up being a matter of Debian policy, even w/o
reproducible builds I guess some approx checks could be implemented
in some future tool, like at least matching file lists and similar.
In any case, I think care should be taken when drafting any such
policy for Debian, because even if I think it's a bad idea to have the
same pkgname-version-arch tuple expose different interfaces when built
with different profiles, this is something the Debian policy might still
want to allow maintainers supporting in their packages, even if not to be
supported for Debian itself (consider cases similar to the mentioned
ldap one), as in for Debian builds.
> 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.
Yes, I don't think this is worth it (at least for now).
> I updated the wiki page accordingly.
Thanks.
> > 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?
Well, let's backtrack a bit, how do you currently handle the
Architecture field in the binary package stanzas in debian/control
restricting the set of produced packages? Because at the end it's
exactly the same issue, and we currently do not propagate that in a
detailed way further on (the Architecture field in .dsc is pretty
broad). It seems you'd need both of those propagated, and it starts to
feel a bit icky somehow.
Thanks,
Guillem
Reply to: