Web lists-archives.com

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




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