[systemd-devel] [RFC] the chopping block

[Lennart Poettering]

On Thu, 11.02.16 23:32, Michael Biebl (mbiebl at gmail.com) wrote:

> 2016-02-11 18:06 GMT+01:00 Lennart Poettering <lennart at poettering.net>:
> > Heya!
> >
> > So I am thinking about some spring cleaning, and would love to remove
> > the following bits from the systemd package:
> >
> > 1) systemd-initctl (i.e. the /dev/initctl SysV compat support). Last
> >    time Debian was still using that, maybe this changed now?
> 
> Debian still uses that, yes. Is this causing any maintenance issues?

It's bitrotting because unmaintained, and I don't like the code. I'd
rather not maintain such legacy stuff.

> It's a pretty isolated component after all.

Well, it's in the systemd repo, which mean I have to take core for it,
but I'd rather not.

What's Debian's strategy for phasing this out? I mean, to say this
clearly: even if we don't delete it today, we'll delete it sooner or
later, hence Debian really should figure out what it wants to do for
this case. Debian could fix sysvinit's reboot to try sending
SIGRMIN+{4,5} to PID 1 in case it needs a poweroff or reboot and
/dev/initctl is not connectable. Or you could maintain the thing
downstream. Or you could suggest people to use 

            "reboot || /usr/bin/kill -RTMIN+4 1" 

or so if they want to downgrade from systemd to sysvinit.

> > 2) compat support for libsystemd-login.so and friends (these were
> >    merged into a single libsystemd.so a long time ago). We are still
> >    building compat libraries to ease the transition, but that was a
> >    long time ago, hence I'd really love to see this go. Any distro
> >    still using this?
> 
> As Martin already pointed out, we dropped the comapt libs a while
> ago.

Excellent!

> > 3) systemd-reply-password – this is really old stuff used by the GNOME
> >    ask-password stuff which was experimental at best, and never found
> >    much use. Unless am very wrong pretty much nobody is using this,
> >    and we can just kill this without replacement. Anybody knows a user
> >    of this that I am not aware of?
> 
> Not actually sure what this tool is actually supposed to do and why it
> was added in the first place.
> Does GNOME shell implement the password agent interface now
> natively?

nope. never did. i figure system-level LUKS disks aren't a priority
for DEs.

> > 5) Here's the controversial one I think: support for booting up
> >    without /var. We have kludges at quite a few places because we
> >    cannot access /var early during boot. I am tempted to stop
> >    supporting this altogether. Of course, this does *not* mean that
> >    people with split off /var would be left in the cold. It just means
> >    that they have to mount /var from the initrd, exactly like this is
> >    already handled from /usr.
> 
> I'm worried about this one. /var can hold a lot of data and is often
> backed by complex setups (iSCSI, nbd, involving remote access).
> Pulling all that into the initramfs seems like a huge amount of
> work.

Well, you have to support that anyway, if you want to allow iscsi-root
and things like that. This should change very little, no?

> Can you enumerate the problems that a split-off of /var is causing?

See other mail.

Lennart

-- 
Lennart Poettering, Red Hat