Quoting Simon McVittie (2018-01-03 14:30:55) > 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>), > which seems like it isn't a great fit for omission of systemd support: > if a package installs systemd units, links to libsystemd, etc., it's > usually because it causes a functional difference to that package's > behaviour on systems that booted with systemd as pid 1, or on systems > where `systemd --user` is available. Main author of that wiki page here. Disclaimer: These "policies" outlined on that page have been agreed upon by the people involved in bootstrapping Debian. AFAIK there was never a project-wide consensus about these rules. The reason why most build profiles completely forbid changes to the produced binary packages is, that otherwise this would undermine the contracts formed by our dependency system. Ultimately, we want to automatically resolve dependency cycles. But reasoning over dependencies in that way is only possible if a binary package with the same name, version and architecture also always contains the same content. Otherwise a package foo (build-)depending on another package bar would not be able to rely on the functionality it expects bar to provide. Ideally, binary packages would even stay the same bit-by-bit. Thus, a package which for example wants to add the nopython build profile would need to move all its Python-specific content into a separate binary package (if that's not the case already) and then not build that binary package if the nopython build profile is active. > The speculation about a possible nosystemd profile in > <https://wiki.debian.org/BuildProfileSpec#Derivative_specific_profiles> is > not consistent with that design principle. If a package contains systemd > units or uses of libsystemd, then it's safe to assume they were added for a > reason. Whether you value that reason or not, it's nearly always true to say > that cutting out systemd-related bits is a functional change. Cutting out systemd-related bits is probably a functional change in most cases. The only way to introduce a nosystemd profile and adhere to the restriction of not introducing functional changes into existing binary packages once that profile is active, would be to add a new set of "nosystemd" binary packages. So the speculation you quote above is consistent with the design principle but it requires invasive changes to the packaging of all packages surrounding systemd. So a debian/control would look like: # this is the normal package Package: foo Build-Profiles: <!nosystemd> Depends: libsystemd, bar, [...] # this is the package built when the nosystemd build profile is active Package: foo-nosystemd Build-Profiles: <nosystemd> Depends: bar, [...] Plus all required changes in debian/rules to support this. Pulling this off while adhering to the existing rules would certainly go beyond the complexity that other build profiles currently require. > 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? > > (Clearly, that would be a silly thing to do, because if you care about > avoiding systemd enough to be specially rebuilding packages, then you > certainly shouldn't boot with systemd as your process 1; but there's no > technical restriction that prevents that from happening.) If such an exception were added, then any tool used for bootstrapping would have to carry a list of profiles that are not safe to use because packages built with that profile do potentially break dependency assumptions. Right now, the only set of build profile names that are allowed to produce binary packages with functional changes is the pkg.$sourcepackage.$anything pattern which allows source package maintainers to experiment. For that reason, I'd like to avoid introducing more build profiles that are allowed to break dependency contracts. Thanks! cheers, josch
Attachment:
signature.asc
Description: signature