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