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. 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. 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.) smcv