Re: Who's locking down the code?
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
Reply to: