Re: Storing build profiles in binary packages (was: Re: Bug#886238: Please introduce official nosystemd build profile)
[ Just few comments to complement josch's veyr nice reply, with which I
completely agree with. ]
On Thu, 2018-01-11 at 00:47:28 +0100, Johannes Schauer wrote:
> Quoting Steve Langasek (2018-01-10 21:49:02)
> > As a policy, I think it's clear that packages built with non-default profiles
> > should never be included in the Debian archive;
>
> Why? By enforcing (via a policy and checkable via reproducible builds) that the
> binary packages that are being built with one (possibly empty) set of build
> profiles active are bit-by-bit identical to those built with a different set of
> build profiles active, it doesn't matter whether a given binary package was
> built with either set.
Yes, and in addition this information is recorded in both .changes
and .buildinfo files. I was initially among the ones wanting this
information in the .debs to be able to trace it, but the need
disappeared when we introduced .buildinfo files, because then we've
got the upload specific recording for the archive processor (.changes),
and the supposedly public facing record of what was done during the
build (.buildinfo), although the later can never be fully trusted
anyway. :)
> > and segregating packages into archives by stage is a sensible way to do this
> > for bootstrapping.
>
> We don't want "stages" for bootstrapping. This is also why the "stage1" and
> "stage2" build profiles are marked as "deprecated" on the wiki page. Those
> profile names are only used by toolchain packages for reasons that go beyond
> the scope of this thread. The reason we don't want "stageX" profiles but
> instead nofoo profiles (disabling foo) are:
>
> - dependency relationships change regularly. Thus, what is a stage1 today
> might not even be needed for bootstrapping anymore tomorrow. But the profile
> might have other uses, for example by downstreams.
>
> - dependency relationships change regularly. Thus the notion of what a
> "stage1" build of a package is also changes regularly. At some point, the
> state of the archive might require a source package to be built without
> libfoo-dev and without libbar-dev. At another point in time, it is
> sufficient to build the source package only without libfoo-dev. At another
> point, it would make sense to build it without libfoo-dev and also without
> libbaz-dev. If there are separate profiles for foo, bar and baz, then an
> automated machinery can exactly choose how to build source packages.
>
> - the functionality removed or changed by a stageX profile might overlap with
> another profile name that is needed for a purpose that is not bootstrapping
> (for example by a downstream). Then, in all places where this functionality
> is activated or deactivated, the full list of profiles that touch it must be
> repeatedly enumerated. It is easier to maintain a single build profile that
> is directly connected with exactly that functionality. See my argument
> about maintainability of build profiles for each distribution in [1].
>
> [1] [🔎] 151553652380.1442.14816198615195092481@localhost">https://lists.debian.org/[🔎] 151553652380.1442.14816198615195092481@localhost
The take home here is that, stages do not scale, they might be fine for
just a toolchain perhaps, but not to automatically bootstrap the entire
build-essential set, or automatically bootstrap dependency cycles.
> > I don't know /what/ one should expect in a world where profiles are used for
> > other purposes but aren't documented in the binary control; I guess it just
> > reinforces the fact that you can't trust third-party deb packages...
>
> With respect to dependencies you already could not trust third-party deb
> packages. In that sense, a binary package built by a third party with a certain
> build profile active is no different than that third party building the same
> source package without build profiles but with an unknown configuration of the
> build system, for example.
Exactly. Or built with build profiles but the field removed afterwards,
or any other number of changes. Anything that lies outside the confines
of a specific distribution can never be fully trusted within that
distribution.
Thanks,
Guillem
Reply to: