On Tue, 2018-01-09 at 05:03 +0000, Wookey wrote: > 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.
And is the reason this is preferable to `dpkg-vendor` based stuff because `dpkg-vendor` cannot affect debian/control in the same way (without tricks to autogenerate control at build time)? > Clearly a downstream distro can instead maintain patches, but we > encourage upstreaming in general and this mechanism allows that. This requires that Debian defines (together with the downstream(s)) a semantic for the profile which satisfies them. Previously in the thread you said "I think that is up to the derivative to define" which I think isn't the case, it has to be a Debian based policy if the patches are to go into Debian. What happens if two downstreams have different ideas of what a given profile should mean? Going down this path starts to look a lot like the USE flags used by source base distros, and while it might be tollerable as a one off it seems likely that once the precedent is established the usage will proliferate (noselinux, noapparmor, nodbus, noblah,...) which would seem to go against our current principal of enabling most options if they cause no harm if not used. I also agree with Russ' point that on the case of `nosystemd` we actually want to be able to support that use case in Debian, and a profile for use by downstreams doesn't appear to satisfy that need. Ian.
