Web lists-archives.com

Storing build profiles in binary packages (was: Re: Bug#886238: Please introduce official nosystemd build profile)

Quoting Steve Langasek (2018-01-10 21:49:02)
> On Mon, Jan 08, 2018 at 08:36:50PM -0500, Michael Stone wrote:
> > On Mon, Jan 08, 2018 at 12:09:09PM -0800, Steve Langasek wrote:
> > > Top-posting to just say +1, and that I was going to reply with much the
> > > same.
> > > I don't even think the requirement for the bootstrap profiles to not
> > > functionally change the packages is necessary, but it's the way the folks
> > > working on bootstrappability have chosen to do it, so it's their call.  But
> > > that's definitely not a binding precedent on other build profiles that might
> > > be implemented.
> > How, then, would you tell by looking at the package name+version which kind
> > of package you have? If you're going to change the name or version string
> > anyway, why use some complicated profile system instead of just applying a
> > patch? This seems overly complicated for simple cases and overly fragile for
> > complex cases.
> The fact that this information is no longer exposed in the binary control
> file is news to me, and very disappointing.  It seems clear to me that one
> *should* be able to determine what profile(s) a package was built with by
> looking at the package itself.


Picture two binary packages with the same name/version/arch tuple, they were
maybe even built by the exact same source package but they were built on
different distributions (or at different times with some build dependencies
having changed) so their contents differ. Even today we are not storing the
information on which platform a source package was built in binary packages. We
only expect binary packages with the same name/version/arch from the same
distribution to play well with each other. And that distribution controls the
build profiles it builds binary packages with. What makes build profiles so
different when you compare it with other factors that change binary package
content? We are also not storing that information in binary packages. But we
have a place to store that information: buildinfo files. Those files also store
with which build profiles a source package was built.

I only see one reason for which one could want to store with which build
profile a package was built in the binary package itself: if that information
becomes relevant for dependency resolution.

Though I guess for downstreams who want to have the Build-Profiles field in the
binary packages they build, I guess there could be a solution involving dpkg

> 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.

> 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] https://lists.debian.org/151553652380.1442.14816198615195092481@localhost

> 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.


cheers, josch

Attachment: signature.asc
Description: signature