Web lists-archives.com

Re: (was: Re: Bug#886238: Please introduce official nosystemd build profile)


Quoting Steve Langasek (2018-01-10 21:52:44)
> On Tue, Jan 09, 2018 at 03:07:01PM +0100, Johannes Schauer wrote:
> > Such a header could be introduced but that would be undesirable for two
> > reasons:
> >  - it would make it hard to check whether the binary packages a source package
> >    produces are really not different with a certain build profile active. Right
> >    now, because of the lack of such a header, we can use the tools from the
> >    reproducible builds project to verify that a build profile does not tamper
> >    with package contents
> >  - right now, a package is uniquely defined by dependency solvers through their
> >    the name/version/architecture tuple. It would be possible to make this a
> >    quadruplet and let packages be unique by their
> >    name/version/architecture/profile property but that would require massive
> >    changes in even more parts of our infrastructure than the introduction of
> >    build profiles already required.
> I think this is an unfortunate case of designing the solution to fit the
> particular set of tools.
> Build profiles, as a general thing (which they are supposed to be - this is
> a major reason support took as long to land in dpkg as it did!), are
> significantly less usable if the build profile doesn't follow the resulting
> .deb as a tag.

Right now, the big difference between build profiles and Gentoo USE flags is,
that build profiles only work for source packages. In contrast to USE flags, it
is (currently) impossible to declare dependencies on binary packages built with
a certain set of build profiles active (or not active). The current crutch we
employ is to make use of the binary package name. By building binary packages
with different names when certain profiles are activated we can use our
existing dependency system.

Our current solution to build profiles does not forbid any future development
that extends the uniqueness of binary packages from name/version/arch to
name/version/arch/profile and introduces a new syntax that allows dependencies
on binary packages with a certain set of profiles activated or deactivated.
This is possible with Gentoo USE flags.

So if we ever decide that we want to make Debian more of a source distribution
and pull a full Gentoo, then we can:

 - come up with a nice syntax for binary package dependencies
 - modify all tools involved in dependency resolution accordingly
 - add the Build-Profiles field to all generated binary packages

If the project at some point in the future decides that this shall be the way
to go, then I shall not stand in the way of such a development. I don't think
that the current way that build profiles work maneuvered us into a dead end if
you have such a future in mind.

But unless we want to pull a full Gentoo here and really make the information
with which build profile a given binary package was built part of the binary
package and thus overhaul all our dependency resolvers, unless the plan is to
do that, I don't see why binary packages should contain this information.

Either it is used for dependency resolution and then we should have the field
or it isn't and then the field is rather making things like comparing packages
with each other difficult. We already accept that the uniqueness of packages
with respect to their name/version/arch only holds within a certain
distribution. But that distribution will also always know with which build
profiles they built all their packages.

So I'm still not convinced.


cheers, josch

Attachment: signature.asc
Description: signature