wild speculations about build profile specification changes
On Tue, Jul 12, 2016 at 05:31:51PM +0200, Johannes Schauer wrote:
> Quoting Javier Serrano Polo (2016-07-10 19:25:59)
> > 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:
>
> https://wiki.debian.org/BuildProfileSpec#Interaction_with_ReproducibleBuilds
>
> 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.
I second this need.
> 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
I think that such a profile list in the spec would make it harder to
maintain. Profile names is what still evolves and continues to evolve.
It also takes away the ability to have private, clean profiles (e.g.
pkg.ghc.noprof for dropping libghc-*-prof).
> 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 actually do not see the profile name as a distinguishing aspect for
whether a profile is clean anymore. While that was the intention, it
clearly does not meet established practise. Some stage and nodoc
profiles are indeed clean.
Thus if we want to have this separation, I believe that it should be at
source package granularity and that it should be a white list (i.e.
default all profiles to dirty).
A rather odd twist of this would be separating the entire profile
namespace by prefixing clean profiles with some kind of marker. I'd see
either annoyingly long profile names or people confused about which one
to use.
In general, I sometimes wish there was a way for packages to explicitly
declare which profiles they support beyond scraping the various fields
that happen to contain them. Maybe a prospective amendment to the
profile syntax could try to address this as well?
> 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?
I see two reasons to dislike killing the field entirely:
* .buildinfo files are not recorded in the archive (yet).
* If your installation breaks for some reason, it would be nice to be
able to tell if any installed packages were built for profiles.
Given that the former is being solved by the reproducible folks and that
we do not record DEB_BUILD_OPTIONS either, maybe these reasons are not
that severe in the end? Maybe the better tradeoff indeed is to kill it.
Helmut
Reply to: