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 discussion. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/
Attachment:
signature.asc
Description: PGP signature