On Sun, 26 Oct 2014, Laurent Bigonville wrote: > It is an habit in debian to compile the packages with as many options > as possible as long as it's not adding pile of new dependencies or > causing issues to the other packages in the archive.
Not an "habit". It is a directive, and we have very good reasons to do so. it is also a *very* old directive as far as I can remember, I think it has been around for at least a decade. > I don't see how a library that turns itself into a noop if PID1 is > not systemd fits into any of these 2 categories in the case of > util-linux (or probably any packages depending against libsystemd0). Indeed. We don't make many exceptions to this, and AFAIK most of them are either related to *very heavy* dependency chains (such as an entire stack of X libraries that depend themselves on font packages, etc), or when the package is very security sensitive and the new dependency adds a considerable security risk due to increased attack surface, or when the package needs to have a very tiny light version for some reason that is *NOT* the installer (for the installer, we use udeb packages). None of those reasons are valid for util-linux and libsystemd0. Now, suppose there was a *strong* technical reason (not a political or ideological one) to have a version of util-linux not linked to libsystemd0. The proper way to do that (and the only one we'd accept) is to have the *SAME SOURCE PACKAGE* (i.e. package util-linux) generate two sets of binary packages. This rule exists to ease future maintenance and security maintenance, and we only accept exceptions to it when non-free dependencies are involved (no package in Debian main may create or depend on non-free packages). > IMHO, if you have the (non-technical?) requirement to not have any > systemd component on your system, you'll have to either start building > your own packages (you can have a look at apt-build) and maybe propose > sensible patches to make it easier for the debian users to opt-out when > rebuilding packages. Or switch to a distribution that allows you to > select which components are enabled at build time. We have a few packages that provide this type of behaviour, they can be built with/without extra dependencies through the use of DEB_BUILD_OPTIONS, but yes, the user must do the dpkg-buildpackage herself. AFAIK, it is used when there is a reasonable common need to extend functionality linking to either non-free, or patent-encumbered code. But we prefer to find a way to do late-linking at runtime instead of that, as it is far more user-friendly... Again, this is not something that would normally be used for stuff like libsystemd0 (or libwrap, or libselinux...). -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141026131637.gc3...@khazad-dum.debian.net