Web lists-archives.com

Bug#886238: Please introduce official nosystemd build profile

On 2018-01-03 13:30 +0000, Simon McVittie wrote:
> On Wed, 03 Jan 2018 at 15:12:51 +0300, Hleb Valoshka wrote:
> > Please introduce official nosystemd build profile so downstream
> > distributions can send patches to package maintainers with
> > systemd-less build instead of keep them in home.
> In general, build profiles are not meant
> to result in functional changes to packages
> (<https://wiki.debian.org/BuildProfileSpec#Profile_built_binary_packages>),

This is correct for the mechanism's main/original purpose of
bootstrapping/removing cyclic dependencies.  The idea is that you
can't change functionality and still use a dependency with the same
name, if you actually want to automate the bootstrap process (because
you don't know which features of a package the depending-on package

> The speculation about a possible nosystemd profile in
> <https://wiki.debian.org/BuildProfileSpec#Derivative_specific_profiles> is
> not consistent with that design principle. 

Right. But I'm not sure that the principles developed around
bootstrapping necessarily have to apply to profiles developed for
other purposes, and especially not for downstream distros who can
define their own policy (within reason).

The other similar example is 'embedded'. You could have an 'embedded'
profile that did more rigorous minimisation of packages for space or
functionality, and exactly what that meant in local policy terms would
be defined by the derivative using it.

> If the nosystemd profile is (exceptionally) allowed to cause functional
> changes, what would the policy be for this build profile? Would it be
> acceptable for a package built with nosystemd to be unusable or have
> incompatible behaviour if it is used on a system booted with systemd?

I think that is up to the derivative to define.

I agree that this matter needs a bit of thought. The profile spec has
evolved quite a lot since the mechanism was initially created. The
focus has very much been on supporting bootstrapping, which provides a
particular set of constraints. 

It's not necessarily wrong to use the mechanism in different ways, but
it does require some thought about the assumptions made by tools to
see if this actually makes sense. Some changes could be too intrusive
to make using build-profiles, and should simply be kept as a
dopwnstream patch, but in practice I expect that a well-defined use
like this would actually work quite well, producing quite clean,
maintainable patches. Ultimately it would be up to maintainers wether
they found it too intrusive or not, and if they did to ask the
derivative to just keep the patch to themselves.
I have not read most of this thread, so this may already have been
said, sorry if I am repeating something. Like Simon and Johannes I am
keen to stick to the technical issue.

I agree with Simon that defining an architecture to try and deal with
this is abuse of that mechanism. An architecture is an ABI and life is
complicated enough without adding baggage to that concept.

Principal hats:  Linaro, Debian, Wookware, ARM

Attachment: signature.asc
Description: PGP signature