Re: Perfect Jessie is something like this...
Christian Seiler <christian@iwakd.de> writes:
> 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.
>
> [...]
>
> 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).
Why at runtime? There would have to be different packages, depending on
what you need. That, too, is a feature of package management: You
install those packages you need and not those you don't need.
> 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.
I am considering Funtoo.
> 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.
That's certainly a problem. I think it's somewhat different in this
case, though: In one case, you have some libraries for things you might
not use. In the other, you have a library just to tell some software
that another software isn't running.
>>> - 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.
I would rather stay free of systemd. The problem is that this is
already pretty much impossible.
> 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?
I've always preferred to have only installed what is needed.
Unfortunately, this has become more and more difficult.
> 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?
It's ok to ship it. It shouldn't be installed when it's not needed.
>>> 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?
yes
> 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.
I'm sure you can :) This has become quite a problem over time.
>>> - 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.
see
It doesn't matter to me whether systemd itself is installed or even
running. I want no part of it.
> 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.
Perhaps see it this way: There are people who don't want systemd and
not any part of it. What's there to discuss?
> 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.
That's also a problem. Why do you need to install more or less all of
gnome just to use a program you find useful? I don't like that at all.
> 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.
I don't think that many, if any, people are emotionally attached to
sysvinit. When someone is, that's IMO a good enough reason for wanting
to stick to it. I don't want to become a slave of the software I'm
using --- and when you think of systemd, it makes me feel like it wants
to enslave everything.
You can't, and should not, go by cold technical reasons or requirements
alone. Doing so would make you as dead as a computer. And it would
make you a bad sysadmin because with all technical knowledge and whatnot
you need, in the end it's your (hard earned) gut feeling and the way you
deal with it which decides whether you're a doing a good job or not.
> 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.
--
Again we must be afraid of speaking of daemons for fear that daemons
might swallow us. Finally, this fear has become reasonable.
Reply to: