Top-posting to just say +1, and that I was going to reply with much the same. I don't even think the requirement for the bootstrap profiles to not functionally change the packages is necessary, but it's the way the folks working on bootstrappability have chosen to do it, so it's their call. But that's definitely not a binding precedent on other build profiles that might be implemented. On Mon, Jan 08, 2018 at 06:37:11PM +0000, Wookey wrote: > 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/ -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: PGP signature