Web lists-archives.com

Re: [yay for broken usage of was: in the Subject header]




Quoting Philipp Kern (2018-01-11 00:20:17)
> On 2018-01-10 22:53, Johannes Schauer wrote:
> > 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.
> Why is it making comparing packages with each other difficult?

What I meant here was what I mentioned elsewhere in this thread. We can check
whether two binary packages built with a different set of build profiles active
are actually the same by using the tools from the reproducible builds project.
And the easiest way to do the comparison is to compare their hashes. If the
build profile would be included, then comparing the packages would be made more
difficult.

> It's an additional annotation of what the package actually contains.

I would rather say that the set of build profiles active is a property of the
*build* and not a property of the binary package. Especially considering that
most build profiles require identical package contents. We also don't store in
binary packages which build dependencies were installed in which version during
the build even though this is also something that can have great influence on
the content of the binary package.  Instead, we store this information in the
buildinfo file which I also find a better fit for storing the information which
build profiles were active because build profiles are a property of the package
build.

> If you upload the set of bootstrap packages and especially if you have
> multiple intermediate stages, you surely would want to know which packages
> will need to be rebuilt to the point of not requiring build profiles anymore,
> no?

At all points during the bootstrapping, we know which source packages we built
with with which profiles active either by simply keeping track of what is being
done or by investigating the generated buildinfo files which contain that
information. It is not necessary to have this information stored in the binary
packages itself for this purpose.

> At the same time for a stable port the archive can ensure that the build
> profile was actually the default one (or accept divergences with a conscious
> decision, like using NEW or BYHAND).

The archive can already do this check by investigating the buildinfo file that
was uploaded together with the binary packages.

> So I don't think it's as black and white wrt full flexibility in dependencies
> as you paint it. :)

Surely, rarely anything is really black and white. :)

Thanks!

cheers, josch

Attachment: signature.asc
Description: signature