Web lists-archives.com

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

On 2018-01-09 15:07 +0100, Johannes Schauer wrote:
> Quoting Wookey (2018-01-09 06:03:26)
> > On 2018-01-08 20:36 -0500, Michael Stone wrote:
> > > How, then, would you tell by looking at the package name+version which kind
> > > of package you have? 
> > The package header says what profiles it was built with. The package
> > name+version doesn't change - that's part of the point. 
> No, there is no header in the binary packages that indicates with which profile
> a source package was built to generate the given binary package.

Oh. OK. My bad - apologies for putting bad info in this already-long
thread.  This was definitiely something we considered along the way
and I had thought it got implemented. Ah and in fact it did, but has
since been removed for reproducible-build compatibility, so I'm out
of date, not wrong :-)

An aside, but I'm not convinced this was the right thing to do. A
reproducible build doesn't mean 'reproductible even if you do
different things, like use a different build profile'. Having the
header had utility.

> Thus, we keep packages built with a different build profile but the same
> name/version/arcitecture bit-by-bit identical to each other.

OK, so the mechanism has morphed quite a lot from Guillem's (and then
my) original ideas, in the light of actually using it, to essentially
only be used at package granularity. And that makes sense because it
preserves the 'name/version/arch' tuple as a dependency identifier.

However we do have 'nodoc', which can't possibly produce bit-by-bit
identical packages (unless the docs are in a separate package) so I
don't see how it can be right to say "packages built with a different
build profile but the same name/version/arcitecture are bit-by-bit
identical to each other". Are you saying that you can't use nodoc if
there are docs in a package, or at least that you can only use it as a
build option, not a build profile?

Again, this is very much policy, not mechanism, and seems to me to be
more restrictive than is necessary.

> Technically speaking you are correct. We can add any arbitrary functionality or
> build dependencies or package sets that are activated or deactivated through a
> certain set of build profiles. It is up to the derivatives which policy they
> use for the technical possibilities that build profiles offer.
> So here on this list we can discuss the policies that we want to use for build
> profiles in Debian. As others already explained, a nosystemd profile does not
> make much sense, even if it were fine to change binary package contents. So we
> could talk about whether we should allow more build profiles that change binary
> package contents but so far I don't see the use case for them and thus the
> discussion would be a bit academic.

I was talking about the general case of the possibilities of use for
build profiles. I have no strong opinion on how well that works in the
particular nosystemd case as I've not followed all that

Principal hats:  Linaro, Debian, Wookware, ARM

Attachment: signature.asc
Description: PGP signature