[systemd-devel] [RFC] the chopping block

[Michael Biebl]

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 a pretty isolated component after all.


> 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.

> 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?

> 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.
Can you enumerate the problems that a split-off of /var is causing?


> 6) The .snapshot unit type. These sounded like a smart idea, I am
>    pretty sure though nobody is using them properly, and they are
>    pretty hard to use. If anything like this should exist at al, then
>    probably as a concept of "transient targets", but not as a separate
>    unit type. Anyone knows any real users of this stuff?

Seems fine to drop.

Michael



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?