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-one should be > trying to put more than one instance of a package built with different > profiles in one repo at one time because stuff will break. But a downstream > distro could enable a profile and build everything that way and that should > be fine. 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. 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. Thus, we keep packages built with a different build profile but the same name/version/arcitecture bit-by-bit identical to each other. > > If you're going to change the name or version string anyway, why use some > > complicated profile system instead of just applying a patch? > > It's not really complicated. It's just a mechanism for variant package > builds which is formalised in dpkg and related tools (without changing > the package name/version). > > And the reason why you'd use it for something like this is that it > lets you upstream patches (which change dependencies) in a reasonably > clean way. > > Clearly a downstream distro can instead maintain patches, but we encourage > upstreaming in general and this mechanism allows that. One has to differentiate between the implementation of build profiles and the policy of how we want to use them in Debian. 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. Thanks! cheers, josch
Attachment:
signature.asc
Description: signature