[systemd-devel] feature request: dlopen

[Luke Kenneth Casson Leighton]

On Tue, Feb 17, 2015 at 9:25 PM, Greg KH <gregkh at linuxfoundation.org> wrote:
> On Tue, Feb 17, 2015 at 08:24:37PM +0000, Luke Kenneth Casson Leighton wrote:
>> so i'm not going to "protest" - i'm going to try a different approach.
>> i'd like you to look at this list of debian packages that are
>> dependent on libsystemd0:
>> http://lkcl.net/reports/removing_systemd_from_debian/list_of_libsystemd0_dependent_packages.txt
>>
>> it's an enormous list, comprising some 15% of the packages present in
>> debian today.  it includes apache2-dev, bluetooth / bluez, the gimp,
>> php, *all* of the video players (xine, mplayer, vlc), *all* of the
>> games and 3D packages that use SDL or pulseaudio (which is most of
>> them), *all* of the major desktop environments including xfce4, lxde,
>> Gnome and KDE/Plasma, cups-daemon, one of the anti-virus daemons, most
>> of the music software packages and services, most of the VoIP clients,
>> the android SDK, the eclipse IDE, OpenJDK 7, erlang, Apache
>> Tomcat..... i'm just absolutely blown away by the extent of the
>> dependencies.
>
> How exactly did you create such a dependancy list?

 apt-rdepends -r libsystemd0 | a bit of awk-style manual magic | sort | uniq

 someone else did a visual-style version of the same thing... i forget
exactly where i saw it - they removed thousands of packages, limiting
it to only about 400, otherwise it would be far too big.

> Perhaps you might wish to just file a Debian bug so that they fix their
> build systems?  Arch Linux doesn't have this kind of requirement, so
> something must be odd here...

 https://wiki.archlinux.org/index.php/systemd
 they moved to systemd, wholesale.

 converting to systemd has become a very rapid, widespread and
wholesale decision that has completely locked out sysvinit, openrc,
*everything*.

 the reason why is because there's no precedent for using dlopen, it's
all compile-time hard dependencies in cups, libpulseaudio, libsdl and
a hundred other immediate dependencies that you can check with
apt-cache rdepends libsystemd0.

 the only major (i say major, they're pretty low down on the list
these days) GNU/Linux distro left which anyone has heard of not using
systemd is slackware.  and that's most likely - this is speculation
btw - because the basis of slackware is "minimal maintainer work".  as
systemd hasn't stabilised, they are probably leaving it.

 gentoo are the only team working to provide alternative
infrastructure.  *all* other major GNU/Linux distros have converted to
systemd and completely abandoned all other options.

 debian does provide systemd-shim, but because of the immediate
hard-compile-time dependencies, you are still left with libsystemd0.

> Also, this is a distro choice to make, the Debian developers seem pretty
> happy with systemd and how it is being loaded in their systems, so
> perhaps you might wish to ask them about this hard-requirement.

> Other distros do not have such a hard-requirement at this time,

 yeah, they do.

> perhaps you
> might wish to try one of them if you do not want to use systemd?

 i manage a dozen systems for clients, many of them remotely, with
absolutely no console access except a computer-illiterate individual
at the keyboard.  i just tried upgrading a system tonight, adding in
the angband.pl nosystemd repository and upgrading it to jessie.

 it completely failed to come back on the VPN network, and because it
is remote i have absolutely no idea why.

 this is *real* bad stuff, greg.  i now have to spend hours, tomorrow,
walking my computer-illiterate friend through the process of
recovering his computer.

 i cannot possibly take the risk of doing such risky upgrades on
systems where my clients are paying money.

 i cannot possibly even _remotely_ contemplate doing a *remote*
conversion of a debian system on which i have five lxc virtual
machines for clients.  it would be completely insane to do so, as i
would not only need to convert the base machine but also the five
client machines all at the same time.

 if the base host machine fails to come up, it costs me a fortune in
KVM access time at the hosting company.

 during the time in which that base machine fails to come up, i have 5
clients all screaming at me "why is my machine not up?"

 then when it is finally up i would have to convert them all over to
the replacement OS as well.

 that's _days_ of work, greg, none of which may be done in a
transitional manner (i moved away from xen two years ago because after
four years of operation it was proving to be too unstable long-term)

 and i am just one systems administrator.  there will be others just
like me - world-wide - who aren't brave enough to speak to you guys
directly, who will be going "oh crap..." and who recognise that they
are being press-ganged into a major decision with absolutely no choice
in the matter.

 even if i was to accept the downtime on my business, unlike many
others in this situation i can't even convert my laptop to FreeBSD
because it has hardware that is too modern and unsupported for
FreeBSD.

 l.