[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: debian-policy: please document build profiles


I'm removing #757760 from the recipients because that bug should contain a
discussion about the implementation of the current build profile spec and
should not be a discussion platform for further additions or changes to the
spec. Lets use debian-dpkg@ to discuss this issue.

Quoting Javier Serrano Polo (2016-07-10 19:25:59)
> On Sat, 09 Jul 2016 23:56:03 +0200 Johannes Schauer <josch@debian.org>
> wrote:
> > I'm CC-ing debian-dpkg@.
> I cannot CC lists.debian.org. You will not see my messages in
> https://lists.debian.org/debian-policy/2016/07/threads.html .

you could subscribe to whitelist@lists.debian.org. That way you can post to all
Debian mailing lists without having to subscribe to them.

> > I suspect you want to express "this package has to be built when no
> > profiles are active as well as when the pkg.linux.zlib profile is
> > active"?
> Yes.
> > If so, then why do you need the Build-Profiles field at all?
> Because the package should not be built if other pkg.linux.* profiles
> are active.

So, what you are suggesting is a short-hand for something where currently you'd
have to write:

Build-Profiles: <!pkg.linux.foo !pkg.linux.bar !pkg.linux.baz ...>

How long will these lists become? Are there many examples of packages where
doing something like this would be desirable?

> > What is your use case?
> There is an introduction at https://bugs.debian.org/830524 . The goal is
> to build a subset of binary packages. For instance, the linux source
> package should have a way to build only linux-image-4.6.0-1-686 (profile
> pkg.linux.686), only linux-image-4.6.0-1-rt-686-pae (profile
> pkg.linux.rt-686-pae), etc. The nodebug profile would be useful to not
> build *-dbg packages.

What you described in that bug seems to be different from your examples. In
your original bug #830524 you propose flavours for packages to build them with
different libc or certain extensions disabled or enabled (Gentoo USE flag
style). Indeed, build profiles are able to give you all that but why is this
useful for src:linux? It seems that you want to build *single* binary packages
only? Why? Is there a reduction in compilation time that you want for debugging
and testing purposes?

> > > I gather that the Built-For-Profiles field is written to DEBIAN/control
> > Why do you want to avoid this field? Why would this be useful?
> Binary packages should be exactly the same as if built without active
> profiles. This helps making and checking a subset of reproducible
> packages.

This problem is already known:


Most build profiles are supposed to create identical binary packages no matter
whether the build profile is active or not. This requirement though is made
impossible by the Built-For-Profiles field which will make the binary packages
unique depending on the active build profiles.

Having the binary packages actually be bit-by-bit identical for all build
profiles that are not supposed to change binary package content would be
desirable because it would

 - allow to check if the policy to not alter the binary package content was
   actually met
 - extend the benefits of the reproducible builds effort to profile built
   binary packages

One way to solve this, would be to change the build profile spec to say that
the Built-For-Profiles field is only to be added if either one of the following
build profiles was active during the build:

 - pkg.$sourcepackage.$anything
 - stage1
 - stage2
 - nodoc

Though I'm not sure whether keeping this static list in dpkg would be very
smart. One way to avoid having to keep a list of "dirty" build profiles in dpkg
would be to extend the requirement of producing identical binary packages to
all profile names. I can see how this would make using above four profiles more
inconvenient. I just still see the temptation of abusing above profile names in
ways that breaks dependency resolvers.

I'm also wondering why keeping the content of the field directly in the binary
package is necessary in the first place. Is it to be able to debug problems
with the binary package later on? We are already throwing away other useful
information about how the binary package was built like:

 - which packages and versions were installed during the build
 - the build path or
 - the time of the build

In fact, all of the above items are part of the .buildinfo file. Binary package
time stamps were one of the last things that got removed from the binary
package meta data. Maybe we should use the same logic and reasoning behind that
change for the content of the Built-For-Profiles field as well and just move it
into the .buildinfo file?

What do you think?


cheers, josch

Attachment: signature.asc
Description: signature

Reply to: