Re: Perfect Jessie is something like this...
Am 26.10.2014 23:38, schrieb lee:
>> libsystemd0 is just 140 KiB and contains utility functions that might be
>> useful for programs interfacing with systemd. It is absolutely harmless
>> on systems with another init system, it will just tell the programs that
>> systemd is not running.
>>
>> logger itself works just fine without systemd being PID1, just the
>> --journald option will not work then.
>
> So now we are supposed to install packages to have software with no
> other function than to tell other software that software we don't have
> installed on our system isn't running.
Yes, but that has always been the case. If you look at Wheezy, then
coreutils (cp, mv, ls, ...) requires the following libraries:
- libacl1
- libattr1
- libselinux1
If you don't use extended attributes, POSIX ACLs or SELinux, you
technically won't need either of those, and you could use coreutils not
linked against these.
But Debian wants to appeal to all sorts of users: people who use POSIX
ACLs and people who don't. People who use SELinux and people who don't.
Take for example the command 'cp -p' (preserve file
attributes/permissions): if you want that command to be able to copy
POSIX ACLs and extended attributes, the cp command must be linked
against libattr1 and libacl1. Otherwise, it can only copy UNIX
permissions and the basic attributes such as modification time. If you
use it to copy files that have none of those, this won't matter and ACL
and xattr support will have no effect, i.e. harmless. But if other
people want to use it on files with xattrs and ACLs, then cp will need
to be linked against those libraries.
Of course, you could devise ever-complicated schemes on how to
dynamically load these dependencies at runtime so that you save a few
KiB in install size and a couple of CPU cycles (which are probably
canceled out by the amount of CPU cycles this more complicated scheme
takes).
But why bother? These types of libraries are relatively small (of the
order of 100 KiB) and have no side effects if the features are not used.
Sure, if you are building an embedded system with just a few megabytes
of flash storage, then even 100 KiB might be a bit much - but Debian
wasn't designed for that, and coreutils (which is the example here that
depends on the aforementioned libraries) is itself ~ 13-14 MiB on Wheezy...
> That's an abuse of dependencies, and I consider it a bug.
If you really want to expunge all code that is even remotely related to
$X (with $X being systemd, SELinux or whatever), you should probably
consider a distribution that allows you to customize your build process,
such as Gentoo.
Binary distributions, unless they wanted to have builds for all possible
combination of features in software (which is an exponentially large
number) will ALWAYS have code installed you are not going to use.
>> - libsystemd0
>> systemd utility functions for use in software interfacing with
>> systemd. Does not require systemd to be PID1.
>
> That shouldn't need to be installed when systemd isn't used.
Let's say I write a daemon that implements systemd's readiness protocol,
and instead of linking against libsystemd0 I just implement the protocol
itself. This will be a bit of code inside the daemon that checks how the
daemon was started and depending on the outcome uses that protocol or
not. This is exactly what the sd_notify() function in libsystemd0 does,
but the protocol is so simple that one can easily do that by hand. Since
the code is harmless when used on non-systemd systems, I always leave it
in and don't provide a possibility for disabling it (since it's not
necessary to disable it).
Then somebody goes on and packages this daemon for Debian. And you find
the functionality provided by that daemon to be useful. Do you then not
use the daemon because it knows how to talk to systemd? The daemon
doesn't use that functionality if started from something else, so it's
not like it's going to affect your system. But it has code in it that in
some way in some shape or form relates to systemd.
A few packages don't only ship init scripts but also systemd service
files. On non-systemd systems those files just lie around and do
nothing. Should packages stop installing them because it's related to
'systemd'? What about upstart init files?
Quite a few packages ship Debian menu files and/or freedesktop.org
.desktop files for the inclusion in menus. For example, bc installs a
Debian menu file. On a server, you might want to have bc (for shell
script automation or the such), but you are probably not going to
install a software that processes the menu files. (Before I get lots of
replies to this: I said probably. ;-)) Should bc not ship this menu file
then?
>> So basically, if you don't want systemd:
>>
>> - you will not get around libsystemd0, but that is really, really
>> harmless (you also don't get grid of libselinux on jessie, but I
>> don't see anybody complaining there, because its functionality is
>> disabled by default, same with libsystemd0 if systemd is not PID1)
>
> libselinux might then also fall under "abuse of dependencies".
What about hardware drivers? You probably will never need about 99% of
hardware drivers installed on your system by the kernel package. Would
you rather have these drivers split up into hundreds of packages and
only install those needed for your hardware?
If I think about it long enough, I can go on and on about lots of
examples where software is installed that you might not technically need.
>> - you will also not really get around udev on Debian, which is also
>> built from the systemd source package (because both are developed in
>> the same source tree), but that's independent of systemd itself
>>
>> - if you don't need logind (i.e. no desktop environment that requires
>> it), then you will need nothing else
>>
>> - if you need logind (i.e. using a desktop environment that requires
>> it), then you will also need to have the systemd package installed
>> (see above: does NOT make systemd PID1, but logind is contained in
>> there), and then you'll also want the systemd-shim if you don't want
>> systemd to be PID1
>
> To sum it up: No matter whether you use systemd or not, Debian depends
> on it.
Define 'systemd'.
systemd as PID1: no, nothing in Debian currently depends on it
exclusively, excluding some specialized packages (such as GUIs to
interface with it etc.).
Parts of the systemd package: yes, Debian will install code from there.
It seems to me that as soon as anything is even remotely connected to
'systemd', you (and some other people posting to these lists)
immediately have some sort of allergic reaction. This makes having a
sensible discussion really, really tedious.
To put this a bit into perspective: I'm not a fan of GNOME. I personally
disagree with many, many design decisions they've made. For example,
while it has gotten better lately, I still think the file dialogs in GTK
are a UX nightmare.[1] Nevertheless, every Linux desktop I have
installed myself contained a TON of GNOME software. I don't use GNOME as
a desktop, so why should I install it or at least large parts of it?
Because they make a lot of USEFUL software. So while I don't agree with
nearly any design decisions they've made, some programs that are
developed under the GNOME umbrella are incredibly useful to me. Am I
giddy with joy every time I have to use a GTK file dialog, e.g. from
wireshark or pdfshuffler? No.[2] But I don't go around and purge every
bit of software that is even remotely connected to GTK/GNOME just
because I don't like many of their decisions.
And even if let's say it was only the case package A that I use depends
on package B for something, and package B also contains a GTK
application (that package A doesn't need), and package B therefore
depends on GTK, and that was the only reason for GTK being pulled into
my system, I still wouldn't complain about the fact that it's there,
even though I technically don't need it.
To me a lot of the anti-systemd response here seems to be a purely
gut-driven emotional response. I realize that what kind of preferences
we have in the software we want to use has a large emotional component.
For example, I don't think you can put my opinion of GNOME into purely
technical terms.[3] So I don't think that it's a bad thing for people to
say "I am emotionally attached to sysvinit and want to keep using it",
but to rant against a dependency on something that DOES NOT PREVENT YOU
from doing so, doesn't seem to be a very rational way of going about
things to me.
Christian
[1] Disclaimer: personal opinion, please don't feel attacked or insulted
if you happen to like them, that's not the point I'm trying to make.
[2] Although to be fair, while I think the KDE one is much better, I'm
not very fond of that one either...
[3] Which is why I only mentioned it here as an example, I don't usually
want to argue subjective things.
Reply to: