Discussion:
[RFC] the chopping block
(too old to reply)
Lennart Poettering
2016-02-11 17:06:45 UTC
Permalink
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?

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?

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?

4) Capabilities= support, i.e. the non-ambient and non-bounding-set kind
of capabilities. They are pretty useless, as fcaps reduce them to
nothing in pretty much all cases, which is precisely why the
ambient caps were created. I am pretty sure nothing uses this, as
it's not realistic to use this at all.

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.

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?

And that's all for now. Opinions?

Lennart
--
Lennart Poettering, Red Hat
Zbigniew Jędrzejewski-Szmek
2016-02-11 17:34:31 UTC
Permalink
Post by Lennart Poettering
Heya!
So I am thinking about some spring cleaning, and would love to remove
1) systemd-initctl (i.e. the /dev/initctl SysV compat support). Last
time Debian was still using that, maybe this changed now?
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?
Fedora ;)
https://bugzilla.redhat.com/show_bug.cgi?id=1125086
But looking at https://bugzilla.samba.org/show_bug.cgi?id=10672#c14
maybe it'd be enough to rebuild samba without the compat headers installed.
Post by Lennart Poettering
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?
4) Capabilities= support, i.e. the non-ambient and non-bounding-set kind
of capabilities. They are pretty useless, as fcaps reduce them to
nothing in pretty much all cases, which is precisely why the
ambient caps were created. I am pretty sure nothing uses this, as
it's not realistic to use this at all.
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.
Dunno, this is a very visible change. How big are the benefits?
Post by Lennart Poettering
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?
Already gone: 36b4a7ba555

Zbyszek
Lennart Poettering
2016-02-11 17:45:52 UTC
Permalink
Post by Zbigniew Jędrzejewski-Szmek
Post by Lennart Poettering
Heya!
So I am thinking about some spring cleaning, and would love to remove
1) systemd-initctl (i.e. the /dev/initctl SysV compat support). Last
time Debian was still using that, maybe this changed now?
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?
Fedora ;)
https://bugzilla.redhat.com/show_bug.cgi?id=1125086
But looking at https://bugzilla.samba.org/show_bug.cgi?id=10672#c14
maybe it'd be enough to rebuild samba without the compat headers
Post by Lennart Poettering
installed.
As long as it's only one package I am happy to break this I must say...
Post by Zbigniew Jędrzejewski-Szmek
Post by Lennart Poettering
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.
Dunno, this is a very visible change. How big are the benefits?
Well, there's no single big benefit, just a lot of small ones
everywhere. We can drop deps from various units, we can do clock
bumping via timestamp files from PID1 and things like that. We could
properly order log message from the PID1 invocation on on systems
lacking an RTC, and so on.
Post by Zbigniew Jędrzejewski-Szmek
Post by Lennart Poettering
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?
Already gone: 36b4a7ba555
Fun! I am an idiot!

Lennart
--
Lennart Poettering, Red Hat
Zbigniew Jędrzejewski-Szmek
2016-02-11 19:44:34 UTC
Permalink
Post by Lennart Poettering
Post by Zbigniew Jędrzejewski-Szmek
Post by Lennart Poettering
Heya!
So I am thinking about some spring cleaning, and would love to remove
1) systemd-initctl (i.e. the /dev/initctl SysV compat support). Last
time Debian was still using that, maybe this changed now?
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?
Fedora ;)
https://bugzilla.redhat.com/show_bug.cgi?id=1125086
But looking at https://bugzilla.samba.org/show_bug.cgi?id=10672#c14
maybe it'd be enough to rebuild samba without the compat headers
Post by Lennart Poettering
installed.
As long as it's only one package I am happy to break this I must say...
I check this now, and samba compiles fine with systemd-compat-libs.rpm
removed. So no problem here.

Our compat support consists of two parts:
libsystemd-{journal,daemon,...}.pc and the .so libraries. I think we
should still keep the .pc files for now.

Zbyszek
Armin K.
2016-02-11 19:46:12 UTC
Permalink
Post by Zbigniew Jędrzejewski-Szmek
Post by Lennart Poettering
Post by Zbigniew Jędrzejewski-Szmek
Post by Lennart Poettering
Heya!
So I am thinking about some spring cleaning, and would love to remove
1) systemd-initctl (i.e. the /dev/initctl SysV compat support). Last
time Debian was still using that, maybe this changed now?
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?
Fedora ;)
https://bugzilla.redhat.com/show_bug.cgi?id=1125086
But looking at https://bugzilla.samba.org/show_bug.cgi?id=10672#c14
maybe it'd be enough to rebuild samba without the compat headers
Post by Lennart Poettering
installed.
As long as it's only one package I am happy to break this I must say...
I check this now, and samba compiles fine with systemd-compat-libs.rpm
removed. So no problem here.
libsystemd-{journal,daemon,...}.pc and the .so libraries. I think we
should still keep the .pc files for now.
Yes, please! I've been doing just that ever since libsystemd was introduced.
Sadly, the change to always install .pc files even when libraries weren't
built was rejected.
Lennart Poettering
2016-02-12 21:16:14 UTC
Permalink
Post by Zbigniew Jędrzejewski-Szmek
Post by Lennart Poettering
Post by Zbigniew Jędrzejewski-Szmek
Post by Lennart Poettering
Heya!
So I am thinking about some spring cleaning, and would love to remove
1) systemd-initctl (i.e. the /dev/initctl SysV compat support). Last
time Debian was still using that, maybe this changed now?
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?
Fedora ;)
https://bugzilla.redhat.com/show_bug.cgi?id=1125086
But looking at https://bugzilla.samba.org/show_bug.cgi?id=10672#c14
maybe it'd be enough to rebuild samba without the compat headers
Post by Lennart Poettering
installed.
As long as it's only one package I am happy to break this I must say...
I check this now, and samba compiles fine with systemd-compat-libs.rpm
removed. So no problem here.
libsystemd-{journal,daemon,...}.pc and the .so libraries. I think we
should still keep the .pc files for now.
Why? do you know any package that still needs it?

Lennart
--
Lennart Poettering, Red Hat
Zbigniew Jędrzejewski-Szmek
2016-02-12 23:37:47 UTC
Permalink
Post by Lennart Poettering
Post by Zbigniew Jędrzejewski-Szmek
Post by Lennart Poettering
Post by Zbigniew Jędrzejewski-Szmek
Post by Lennart Poettering
Heya!
So I am thinking about some spring cleaning, and would love to remove
1) systemd-initctl (i.e. the /dev/initctl SysV compat support). Last
time Debian was still using that, maybe this changed now?
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?
Fedora ;)
https://bugzilla.redhat.com/show_bug.cgi?id=1125086
But looking at https://bugzilla.samba.org/show_bug.cgi?id=10672#c14
maybe it'd be enough to rebuild samba without the compat headers
Post by Lennart Poettering
installed.
As long as it's only one package I am happy to break this I must say...
I check this now, and samba compiles fine with systemd-compat-libs.rpm
removed. So no problem here.
libsystemd-{journal,daemon,...}.pc and the .so libraries. I think we
should still keep the .pc files for now.
Why? do you know any package that still needs it?
Not everything is packaged, people might have other code.
There is no maintenance cost, it's just four tiny text files.
So if we remove something that was documented as an official
interface, I think there should be a clear saving.

Zbyszek
Lennart Poettering
2016-02-13 10:27:35 UTC
Permalink
Post by Zbigniew Jędrzejewski-Szmek
Post by Lennart Poettering
Post by Zbigniew Jędrzejewski-Szmek
Post by Lennart Poettering
As long as it's only one package I am happy to break this I must say...
I check this now, and samba compiles fine with systemd-compat-libs.rpm
removed. So no problem here.
libsystemd-{journal,daemon,...}.pc and the .so libraries. I think we
should still keep the .pc files for now.
Why? do you know any package that still needs it?
Not everything is packaged, people might have other code.
There is no maintenance cost, it's just four tiny text files.
So if we remove something that was documented as an official
interface, I think there should be a clear saving.
Well, but we really want people to fix up their stuff eventually. I am
fine with maintaining compat for a while, and we did for 2y, but I am
very sure we should be strict after the transition phase and cut
things off. There *must* always be a strategy how to finish the
transition, and they only viable strategy I see is to make a hard cut
after a long transition phase, and I think that's now.

In general, I think ABI compatibility is a ton more relevant than mere
API compatibility anyway. Maintaining ABI compat means being nice to
users, and I think that's worth a lot. But providing API compat that
requires only a rebuild to fix ABI is just a service to developers,
and that's far less of a priority.

Moreover, the .so files we shipped for the last 2y generated linker
warnings anyway, so people should really have noticed. And fixing
their build is still trivially easy, it just means changing the
pkg-config line in their configure script a tiny bit.

I think we should cut this off fully. Let's please get rid of this
bitrotting crap now!

Lennart
--
Lennart Poettering, Red Hat
Jóhann B. Guðmundsson
2016-02-11 20:04:08 UTC
Permalink
Post by Lennart Poettering
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?
Fedora;)
https://bugzilla.redhat.com/show_bug.cgi?id=1125086
But looking athttps://bugzilla.samba.org/show_bug.cgi?id=10672#c14
maybe it'd be enough to rebuild samba without the compat headers installed.
The upstream bug is few months short of it's 2 year anniversary and this
move will just get the samba developers to apply the patch in that
upstream report and close that bug.

Andrew is there any reason the patch in that upstream report has not
been applied and samba moved to use libsystemd.so?

JBG
Armin K.
2016-02-11 20:41:05 UTC
Permalink
Post by Lennart Poettering
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?
Fedora;)
https://bugzilla.redhat.com/show_bug.cgi?id=1125086
But looking athttps://bugzilla.samba.org/show_bug.cgi?id=10672#c14
maybe it'd be enough to rebuild samba without the compat headers installed.
The upstream bug is few months short of it's 2 year anniversary and this move will just get the samba developers to apply the patch in that upstream report and close that bug.
Andrew is there any reason the patch in that upstream report has not been applied and samba moved to use libsystemd.so?
It has been applied at least since the last summer.
Jóhann B. Guðmundsson
2016-02-11 21:30:15 UTC
Permalink
Post by Armin K.
Post by Lennart Poettering
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?
Fedora;)
https://bugzilla.redhat.com/show_bug.cgi?id=1125086
But looking athttps://bugzilla.samba.org/show_bug.cgi?id=10672#c14
maybe it'd be enough to rebuild samba without the compat headers installed.
The upstream bug is few months short of it's 2 year anniversary and this move will just get the samba developers to apply the patch in that upstream report and close that bug.
Andrew is there any reason the patch in that upstream report has not been applied and samba moved to use libsystemd.so?
It has been applied at least since the last summer.
If that's the case the samba community does not close open bugs as
fixed, what a waste of time that must be for everybody anyway then the
only concern ( thus far ) has already been fixed upstream.

JBG
Jóhann B. Guðmundsson
2016-02-11 23:50:28 UTC
Permalink
Post by Jóhann B. Guðmundsson
Post by Lennart Poettering
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?
Fedora;)
https://bugzilla.redhat.com/show_bug.cgi?id=1125086
But looking athttps://bugzilla.samba.org/show_bug.cgi?id=10672#c14
maybe it'd be enough to rebuild samba without the compat headers installed.
The upstream bug is few months short of it's 2 year anniversary and this
move will just get the samba developers to apply the patch in that
upstream report and close that bug.
Andrew is there any reason the patch in that upstream report has not
been applied and samba moved to use libsystemd.so?
There isn't a patch for upstream master and the 4.1 patch doesn't
apply.
(I realise it may be trivial to fix it, but we need it tested against
old and new systemd installs etc, so if I can get such a patch it will
be much easier)
Sorry,
There was someone ( Armin ) on this thread that responded this had
already been applied upstream since last summer which inconsistent with
the current status of the bug in your tracker and your response and I
think it's safe to assume you know better anyway you are aware of what's
about to take place and need to adjust accordingly as do rest of
downstreams that still might be using/relying on this although ( thus
far ) samba seems to be the only affected by this change.

JBG
Matthias Urlichs
2016-02-11 17:29:46 UTC
Permalink
Hi,
Post by Lennart Poettering
5) Here's the controversial one I think: support for booting up
without /var.
Meh. I have quite a few multi-boot systems with a common /var/log
partition. Plus, unlike the other "spring cleaning" changes this would
cause a boot failure after update.

Thus: if you must, deprecate this now, but please leave the actual code
alone until next spring.
--
-- Matthias Urlichs
Lennart Poettering
2016-02-11 17:49:49 UTC
Permalink
Post by Matthias Urlichs
Hi,
Post by Lennart Poettering
5) Here's the controversial one I think: support for booting up
without /var.
Meh. I have quite a few multi-boot systems with a common /var/log
partition. Plus, unlike the other "spring cleaning" changes this would
cause a boot failure after update.
Again: this does not break systems with split off /var, as I tried to
make very clear in my original mail. All that's needed is that the
initrd mounts /var before handing off control to the main system.

The initrd already does that for / and for /usr, hence /var is just
one more step.

Lennart
--
Lennart Poettering, Red Hat
Matthias Urlichs
2016-02-11 18:18:50 UTC
Permalink
Post by Lennart Poettering
Again: this does not break systems with split off /var, as I tried to
make very clear in my original mail. All that's needed is that the
initrd mounts /var before handing off control to the main system.
I know that. Please don't assume that I misunderstood you just because
every systemd-basher during the last five years did the same thing. :-P

However, it *does* break systems which do not mount /var in their initrd
despite having /var (or a piece thereof) split off.
Such changes should have a "deprecated" phase between "works fine" and
"needs manual intervention".

The number of such systems is definitely not zero. In addition to
multi-boot machines with shared /var/{log,tmp,cache} sub-mounts, there's
the "somewhat-embedded system with root on SDHC card and /var on hard
disk / NFS / whatever" usecase. Some of these may not even *have* an initrd.
--
-- Matthias Urlichs
Reindl Harald
2016-02-11 18:22:40 UTC
Permalink
Post by Matthias Urlichs
Post by Lennart Poettering
Again: this does not break systems with split off /var, as I tried to
make very clear in my original mail. All that's needed is that the
initrd mounts /var before handing off control to the main system.
I know that. Please don't assume that I misunderstood you just because
every systemd-basher during the last five years did the same thing. :-P
However, it *does* break systems which do not mount /var in their initrd
despite having /var (or a piece thereof) split off.
Such changes should have a "deprecated" phase between "works fine" and
"needs manual intervention"
a *really* common setup is *only* /var/log as a own partition or on
virtual machines a own disk (since it makes zero sense their use more
than one partition)
Lennart Poettering
2016-02-12 21:12:45 UTC
Permalink
Post by Matthias Urlichs
Post by Lennart Poettering
Again: this does not break systems with split off /var, as I tried to
make very clear in my original mail. All that's needed is that the
initrd mounts /var before handing off control to the main system.
I know that. Please don't assume that I misunderstood you just because
every systemd-basher during the last five years did the same thing. :-P
However, it *does* break systems which do not mount /var in their initrd
despite having /var (or a piece thereof) split off.
Such changes should have a "deprecated" phase between "works fine" and
"needs manual intervention".
Well, it's just a matter of shifting responsibilities between systemd
and the initrd, that's all. I'd really like to see this responsibility
being moved over to the initrd, like we already did for the /usr case.

Lennart
--
Lennart Poettering, Red Hat
Colin Guthrie
2016-02-12 10:04:19 UTC
Permalink
Post by Lennart Poettering
Post by Matthias Urlichs
Hi,
Post by Lennart Poettering
5) Here's the controversial one I think: support for booting up
without /var.
Meh. I have quite a few multi-boot systems with a common /var/log
partition. Plus, unlike the other "spring cleaning" changes this would
cause a boot failure after update.
Again: this does not break systems with split off /var, as I tried to
make very clear in my original mail. All that's needed is that the
initrd mounts /var before handing off control to the main system.
The initrd already does that for / and for /usr, hence /var is just
one more step.
Hmmm, has all the split-usr code been fully removed from systemd now? A
quick grep suggests not.

While I don't personally have a problem with this removal, I do think
that comparing it to /usr is bogus.

While you may not *support* /usr being split out and mounted by /, it
does still work and systemd *is* still sympathetic to that.

The situation with /var is much more brutal. You're suggesting that it
would now be something that *has* to be done by the initrd and if you go
down that route, you may as well ditch all the split-usr stuff too as if
the initrd *has* to mount /var, it may as well do /usr too now even if
there were some hold outs.


Like I say, I get your reasoning for wanting to do this, but it's not
really comparable to /usr support.


Col
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
Tribalogic Limited http://www.tribalogic.net/
Open Source:
Mageia Contributor http://www.mageia.org/
PulseAudio Hacker http://www.pulseaudio.org/
Trac Hacker http://trac.edgewall.org/
Lennart Poettering
2016-02-12 21:08:24 UTC
Permalink
Post by Colin Guthrie
Post by Lennart Poettering
Post by Matthias Urlichs
Hi,
Post by Lennart Poettering
5) Here's the controversial one I think: support for booting up
without /var.
Meh. I have quite a few multi-boot systems with a common /var/log
partition. Plus, unlike the other "spring cleaning" changes this would
cause a boot failure after update.
Again: this does not break systems with split off /var, as I tried to
make very clear in my original mail. All that's needed is that the
initrd mounts /var before handing off control to the main system.
The initrd already does that for / and for /usr, hence /var is just
one more step.
Hmmm, has all the split-usr code been fully removed from systemd now? A
quick grep suggests not.
Well, we support installing the package with split bin directories,
but we don't really support booting without /usr around. I mean, udev
rules aren't restarted as soon as /usr and the binaries on it become
available, hence it simply cannot work correctly to have /usr not
available during early boot. If distros claim that, they are just
lying to themselves and their users... (note that many packages
install their own udev rules, such as sane, udisks and so on, and they
are generally located in /usr, hence they all, together with *all*
their deps – which include things such as glib and so on – would have
to be placed in /, too, but to my knowledge no distro does that).

The only things we official support:

a) / and /usr are on one file system, either with or without initrd
b) / and /usr are split, but then you have to mount it from the
initrd, and you need one
Post by Colin Guthrie
While I don't personally have a problem with this removal, I do think
that comparing it to /usr is bogus.
Well, it's the same thing, really. We'd just make the change to say
that /, /usr and /var either have to be all on the same fs, in which
case initrd and non-initrd boots are supported. Or people can split up
/, /usr and /var into as many pieces as they like, but in that case an
initrd has to be in place and mount things before the system
transitions to the host init system.
Post by Colin Guthrie
While you may not *support* /usr being split out and mounted by /, it
does still work and systemd *is* still sympathetic to that.
Not really.
Post by Colin Guthrie
The situation with /var is much more brutal. You're suggesting that it
would now be something that *has* to be done by the initrd and if you go
down that route, you may as well ditch all the split-usr stuff too as if
the initrd *has* to mount /var, it may as well do /usr too now even if
there were some hold outs.
Well, not mounting /usr in the initrd is pretty much broken, except
that some exotic cases might still work superficially (i.e systems
where you install zero other packages, and no sane, no udisks, and
nothing like that), but not really. And it would be the exact same
with /var. Sure, we'd still boot up, and a lot of stuff will still
appear to work, execept that it's actually pretty fucked.

Lennart
--
Lennart Poettering, Red Hat
Andrei Borzenkov
2016-02-11 17:48:15 UTC
Permalink
Post by Lennart Poettering
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.
Does it apply to whole /var, to each part of /var or to specific subdirs
in /var? In openSUSE various subtrees under /var are split off in
individual volumes on btrfs, forcing mounting them all in initrd is not
much appealing.
Lennart Poettering
2016-02-11 17:52:23 UTC
Permalink
Post by Andrei Borzenkov
Post by Lennart Poettering
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.
Does it apply to whole /var, to each part of /var or to specific subdirs
in /var? In openSUSE various subtrees under /var are split off in
individual volumes on btrfs, forcing mounting them all in initrd is not
much appealing.
btrfs's subvolumes are pretty nice as they are just special
directories. There's no need to mount them in any special way.

That said, this is about /var/log and these kinds of things. If some
random late-boot package needs something under /var (let's say mysql
needs /var/lib/mysql), then systemd really doesn't care about it...

Lennart
--
Lennart Poettering, Red Hat
Andrei Borzenkov
2016-02-11 17:57:03 UTC
Permalink
Post by Lennart Poettering
Post by Andrei Borzenkov
Post by Lennart Poettering
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.
Does it apply to whole /var, to each part of /var or to specific subdirs
in /var? In openSUSE various subtrees under /var are split off in
individual volumes on btrfs, forcing mounting them all in initrd is not
much appealing.
btrfs's subvolumes are pretty nice as they are just special
directories. There's no need to mount them in any special way.
There is, but this is off topic here.
Post by Lennart Poettering
That said, this is about /var/log and these kinds of things. If some
You will need to be specific, which kind of things then. And yes,
/var/log is mount point by default as well. Please if you are going to
drop support for these things being mount point, list them precisely and
exhaustively.
Post by Lennart Poettering
random late-boot package needs something under /var (let's say mysql
needs /var/lib/mysql), then systemd really doesn't care about it...
Lennart
Lennart Poettering
2016-02-11 17:59:25 UTC
Permalink
Post by Andrei Borzenkov
Post by Lennart Poettering
Post by Andrei Borzenkov
Post by Lennart Poettering
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.
Does it apply to whole /var, to each part of /var or to specific subdirs
in /var? In openSUSE various subtrees under /var are split off in
individual volumes on btrfs, forcing mounting them all in initrd is not
much appealing.
btrfs's subvolumes are pretty nice as they are just special
directories. There's no need to mount them in any special way.
There is, but this is off topic here.
Post by Lennart Poettering
That said, this is about /var/log and these kinds of things. If some
You will need to be specific, which kind of things then. And yes,
/var/log is mount point by default as well. Please if you are going to
drop support for these things being mount point, list them precisely and
exhaustively.
Well, /var/log/journal/* /var/lib/systemd/* is what I personally care about.

Lennart
--
Lennart Poettering, Red Hat
Tom Gundersen
2016-02-11 17:58:27 UTC
Permalink
Post by Lennart Poettering
Heya!
So I am thinking about some spring cleaning, and would love to remove
All this looks good to me.
Post by Lennart Poettering
1) systemd-initctl (i.e. the /dev/initctl SysV compat support). Last
time Debian was still using that, maybe this changed now?
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?
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?
4) Capabilities= support, i.e. the non-ambient and non-bounding-set kind
of capabilities. They are pretty useless, as fcaps reduce them to
nothing in pretty much all cases, which is precisely why the
ambient caps were created. I am pretty sure nothing uses this, as
it's not realistic to use this at all.
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.
This would be particularly nice (and controversial for sure). I totally
agree that this should be very doable though, as all the initrd
infrastructure is already there. The way things are now with no /var at
early boot is sort of idiotic I must say. Big +1 from me.
Post by Lennart Poettering
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?
And that's all for now. Opinions?
Jóhann B. Guðmundsson
2016-02-11 19:37:33 UTC
Permalink
Post by Lennart Poettering
Heya!
So I am thinking about some spring cleaning, and would love to remove
All seem to be very sound choice to make.

Arguably you should chop away the environment files support in the
process since you are already wielding the axe...

JBG
Reindl Harald
2016-02-11 20:39:00 UTC
Permalink
Post by Jóhann B. Guðmundsson
Arguably you should chop away the environment files support in the
process since you are already wielding the axe...
no - damned there are a ton of reasons to use them where it *do not
matter* if you would do whatever this way or not

they can be shared between a dozens sepearated but related local
services what you can't do with systemd snippets

please refrain from propose remove *useful* featzres with *zero*
maintaince costs just because *you* won't use them - just don't use them
and you are done but stop trying to dicatate the world how all others
have to configure their systems - it's NOT your business
Lennart Poettering
2016-02-12 21:15:35 UTC
Permalink
Post by Jóhann B. Guðmundsson
Arguably you should chop away the environment files support in the
process since you are already wielding the axe...
no - damned there are a ton of reasons to use them where it *do not matter*
if you would do whatever this way or not
Not this again!

Johann, Reindl, the next time you start flaming each other about the
EnvironmentFile= thing again on this ML I'll put both of you on moderation,
reagrdless who started it.

We had this discussion many times, I made clear that I think
EnvironmentFile= was a mistake, but that it will stay, and that's
really the end of the story.

Lennart
--
Lennart Poettering, Red Hat
Martin Pitt
2016-02-11 20:59:59 UTC
Permalink
Hello,

answering for Debian/Ubuntu.
Post by Lennart Poettering
1) systemd-initctl (i.e. the /dev/initctl SysV compat support). Last
time Debian was still using that, maybe this changed now?
This would apply if you boot with systemd, then install sysvinit, and
want to reboot the machine (using SysV's /sbin/reboot), right? Or the
other way around?

This is still somewhat relevant for Debian, but maybe there's
something simpler that can be done for that case? If there's any other
way to reboot the machine in that situation, it can also become
documentation.

Not relevant for Ubuntu.
Post by Lennart Poettering
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?
D/U dropped the compat libs months ago.
Post by Lennart Poettering
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?
First time I hear about it TBH. I'm not a GNOME-y/desktop-y person any
more, but this suggests that it's nowhere being used except for the
rather old systemd-ui:
https://codesearch.debian.net/perpackage-results/systemd-reply-password/2/page_0

dracut apparently installs it into the generated initrd, but that's a
trivial thing to drop.
Post by Lennart Poettering
5) Here's the controversial one I think: support for booting up
without /var.
Some deprecation time would be appreciated, so that we have time to
adjust initramfs-tools, at least for common cases. Traditionally /var
has never been required for early boot, thus there are a fair number
of people using /var on NFS (judging by bug reports that we get), and
squeezing that into an initrd might cause some trouble.

Thanks,

Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
Martin Pitt
2016-02-11 21:11:21 UTC
Permalink
Post by Martin Pitt
This would apply if you boot with systemd, then install sysvinit, and
want to reboot the machine (using SysV's /sbin/reboot), right? Or the
other way around?
This is still somewhat relevant for Debian, but maybe there's
something simpler that can be done for that case? If there's any other
way to reboot the machine in that situation, it can also become
documentation.
... I figure "systemctl reboot" should do?

Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
Reindl Harald
2016-02-11 21:17:13 UTC
Permalink
Post by Martin Pitt
Post by Martin Pitt
This would apply if you boot with systemd, then install sysvinit, and
want to reboot the machine (using SysV's /sbin/reboot), right? Or the
other way around?
This is still somewhat relevant for Debian, but maybe there's
something simpler that can be done for that case? If there's any other
way to reboot the machine in that situation, it can also become
documentation.
... I figure "systemctl reboot" should do?
"reboot -f" helped a lot for the *one time change* as systemd was
introdocued into Fedora long ago.....
Lennart Poettering
2016-02-12 21:24:37 UTC
Permalink
Post by Martin Pitt
Hello,
answering for Debian/Ubuntu.
Post by Lennart Poettering
1) systemd-initctl (i.e. the /dev/initctl SysV compat support). Last
time Debian was still using that, maybe this changed now?
This would apply if you boot with systemd, then install sysvinit, and
want to reboot the machine (using SysV's /sbin/reboot), right? Or the
other way around?
yeah, it's about making legacy tools speak to systemd. i.e. you booted
up with systemd, and now want to use sysv "reboot" to reboot the
system. i.e for downgrading from systemd to sysvinit.
Post by Martin Pitt
This is still somewhat relevant for Debian, but maybe there's
something simpler that can be done for that case? If there's any other
way to reboot the machine in that situation, it can also become
documentation.
You can send SIGINT to PID 1. Tha triggers a reboot on both sysvinit
and systemd.
Post by Martin Pitt
Not relevant for Ubuntu.
Post by Lennart Poettering
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?
D/U dropped the compat libs months ago.
very good!

Given that fedora got rid of it too with the exception of samba (which
as reported seems to have been fixed upstream already), I think we can
kill this now.
Post by Martin Pitt
Post by Lennart Poettering
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?
First time I hear about it TBH. I'm not a GNOME-y/desktop-y person any
more, but this suggests that it's nowhere being used except for the
https://codesearch.debian.net/perpackage-results/systemd-reply-password/2/page_0
dracut apparently installs it into the generated initrd, but that's a
trivial thing to drop.
That sounds very wrong. I'll ping Harald!

Lennart
--
Lennart Poettering, Red Hat
Michael Biebl
2016-02-11 22:32:42 UTC
Permalink
Post by Lennart Poettering
Heya!
So I am thinking about some spring cleaning, and would love to remove
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.
Post by Lennart Poettering
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.
Post by Lennart Poettering
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?
Post by Lennart Poettering
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?
Post by Lennart Poettering
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?
Lennart Poettering
2016-02-12 21:32:07 UTC
Permalink
Post by Michael Biebl
Post by Lennart Poettering
Heya!
So I am thinking about some spring cleaning, and would love to remove
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.
Post by Michael Biebl
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.
Post by Michael Biebl
Post by Lennart Poettering
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!
Post by Michael Biebl
Post by Lennart Poettering
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.
Post by Michael Biebl
Post by Lennart Poettering
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?
Post by Michael Biebl
Can you enumerate the problems that a split-off of /var is causing?
See other mail.

Lennart
--
Lennart Poettering, Red Hat
Simon McVittie
2016-02-12 17:49:23 UTC
Permalink
Post by Lennart Poettering
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 don't think /var is really the same thing as /usr: for a start, it has
to be read/write, whereas /usr and / can be read-only for at least the
early stages of boot.

On stateless systems with a read-only / and /etc, requiring /var to be
mounted from the initramfs would mean that the mechanism for setting up
/var (NFS or tmpfs or whatever) would have to move into the initramfs.

Which specific subdirectories of /var do you want mounted before pid 1
starts? Presumably /var/lib/systemd and /var/log, and everything that's
necessary to mount those, but not necessarily their siblings?

Would it be feasible to buffer read/write stuff in /run until /var comes
up, and then write it out afterwards? (I realise that's already how some
of it works, notably the Journal.)
--
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>
Lennart Poettering
2016-02-12 21:34:38 UTC
Permalink
Post by Simon McVittie
Post by Lennart Poettering
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 don't think /var is really the same thing as /usr: for a start, it has
to be read/write, whereas /usr and / can be read-only for at least the
early stages of boot.
On stateless systems with a read-only / and /etc, requiring /var to be
mounted from the initramfs would mean that the mechanism for setting up
/var (NFS or tmpfs or whatever) would have to move into the
initramfs.
Since initrds tend to cover root-on-nfs, root-on-iscsi and so on
anyway, that sounds like no change in behaviour really..
Post by Simon McVittie
Which specific subdirectories of /var do you want mounted before pid 1
starts? Presumably /var/lib/systemd and /var/log, and everything that's
necessary to mount those, but not necessarily their siblings?
Yeah, mostly those, see other mail.
Post by Simon McVittie
Would it be feasible to buffer read/write stuff in /run until /var comes
up, and then write it out afterwards? (I realise that's already how some
of it works, notably the Journal.)
That's what we do currently. I'd love to reduce this.

Lennart
--
Lennart Poettering, Red Hat
Christian Seiler
2016-02-12 23:10:20 UTC
Permalink
Post by Lennart Poettering
Post by Simon McVittie
Post by Lennart Poettering
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 don't think /var is really the same thing as /usr: for a start, it has
to be read/write, whereas /usr and / can be read-only for at least the
early stages of boot.
On stateless systems with a read-only / and /etc, requiring /var to be
mounted from the initramfs would mean that the mechanism for setting up
/var (NFS or tmpfs or whatever) would have to move into the
initramfs.
Since initrds tend to cover root-on-nfs, root-on-iscsi and so on
anyway, that sounds like no change in behaviour really..
Well, kind-of. The root-on-nfs and root-on-iscsi are dumbed-down
versions of what's possible once a system is booted.



iSCSI: currently the rootfs works fine, because for the rootfs one
can easily tell the initramfs implementation explicitly that it's
on iSCSI. If your rootfs is on network storage, you have to do so
anyway, so that's not an issue.

But there's no way to determine *just* from looking at /etc/fstab
that a given file system is on iSCSI (or nbd for that matter),
because those just look like regular SCSI block devices (which
don't exist yet if the initramfs hasn't logged in to the iSCSI
session).

This is already somewhat problematic for /usr, but since I've never
seen a setup where people put /usr on iSCSI but / not, so this
was never a huge issue in that regard.

On the other hand, what I have seen in practice are systems with
/var/log on iSCSI.

Also, if you look at how iSCSI login in initramfs works currently,
it's basically just running a binary called 'iscsistart' that tells
the kernel to log in to a specific session where the rootfs is on,
the real daemon isn't started yet. So only a specific session
that is configured separately (!) from all the other configured
sessions is logged into in the initramfs - and the daemon that
reads the proper configuration is only started after the system has
booted.

So in order to support generic filesystems on iSCSI in initramfs,
one would need to start the full daemon already in the initramfs,
plus the full configuration database must be available in the
initramfs (which can change with just some admin commands, after
which the admin would need to remember to regenerate the
initramfs image), and the daemon would need to be modified to
support that.





NFS:

nfsroot is supported only for NFSv2/3 and (depending on the
initramfs implementation) in NFSv4 with sec=sys without idmapping.
If you need NFSv4 with idmapping or want to actually have a secure
NFS mount (e.g. encrypted + authenticated via Kerberos), that
currently doesn't work at all from the initramfs. idmapping
requires that request-key works within the initramfs and properly
calls the nfsidmap binary, which will in turn usually require
the full NSS stack of the system to be available. For Kerberos
you need rpc.svcgssd to be running, as well as have a program like
k5start running to get a ticket for the root user, otherwise the
file system is inaccessible on a kernel level. (And Kerberos also
requires idmapping btw.) Also, in contrast to e.g. iSCSI, where
you could probably get away with killing the daemon before
switching to the rootfs, and then restarting the daemon, both the
idmapping binaries and the rpc.svcgssd have to remain available,
(the former as an upcall from the kernel, the latter as a running
daemon), otherwise the kernel won't be able to properly handle
the filesystem.






And NFS and iSCSI are just two things I have quite a bit of
experience with. You could also imagine that people put /var/log
on sshfs, or any other FUSE filesystem for that matter, which as
of now works, but will break if you introduce the change, because
the vast majority of FUSE filesystems (if any at all) support
running from initramfs. Or you could have /var/log as a bind
mount of a directory within an OCFS2 filesystem on a multi-master
DRBD. It's not that difficult to set up on a normal system, but
good luck getting that to work from an initramfs.





Of course, it's not impossible to make all these setups work.
But it would require changes to a lot of other software that's
currently used, which are probably going to be relatively
painful and it's going to be a lot of work for a lot of other
people.

The maintenance burden in systemd for buffering things in /run
before /var, /var/log, etc. are available is minuscule compared
to that amount of pain this change would cause other people.
Which in turn means what would more likely happen is that this
would not be implemented in many cases and then once the version
of systemd with this requirement hits distributions, this would
break users' systems without them being able to run their setup
as designed. I think that would be really bad.

Note that this is different from /usr: not-mounted /usr was
already broken beforehand, which /var currently isn't. A lot of
the scenarios I've described above haven't worked for /usr
beforehand anyway (e.g. I haven't seen a single distribution
that didn't have Kerberos stuff in /usr even before any UsrMerge
so that /usr via Kerberized NFSv4 wasn't possible anyway) and so
there were already many, many more constraints for /usr, so that
the breakage in that case was quite limited. Also, in contrast
to /usr, where a merged /usr actually has very real advantages,
such as enabling stateless systems, I don't see any advantages
for /var here, other than making systemd simpler in a very
minuscule way.

I don't think that trade-off is warranted.

Regards,
Christian

PS: Btw. if you do run journald already in initramfs (which I
think is a good thing to have), then it still needs to have
code to flush /run/log/journal to /var/log/journal. So in that
case you don't actually gain anything.
Lennart Poettering
2016-02-13 12:01:22 UTC
Permalink
Post by Christian Seiler
Post by Lennart Poettering
Post by Simon McVittie
Post by Lennart Poettering
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 don't think /var is really the same thing as /usr: for a start, it has
to be read/write, whereas /usr and / can be read-only for at least the
early stages of boot.
On stateless systems with a read-only / and /etc, requiring /var to be
mounted from the initramfs would mean that the mechanism for setting up
/var (NFS or tmpfs or whatever) would have to move into the
initramfs.
Since initrds tend to cover root-on-nfs, root-on-iscsi and so on
anyway, that sounds like no change in behaviour really..
Well, kind-of. The root-on-nfs and root-on-iscsi are dumbed-down
versions of what's possible once a system is booted.
Well, to my understanding dracut and stuff makes pretty much all
storage tech that is available during the normal system also available
in the initrd, with the same software, to make sure testing stays
managable. It waits for the root disk and for /usr with the same
machanics (i.e. the systemd logic of .device units, fsck services and
.mount units). And quite frankly that's really how an initrd should
work really: use the same logic and the same software as the host
would...

I think you are extrapolating from limitations of one specific initrd
implementation, no? It sounds really as if that implementation should
be fixed though...
Post by Christian Seiler
PS: Btw. if you do run journald already in initramfs (which I
think is a good thing to have), then it still needs to have
code to flush /run/log/journal to /var/log/journal. So in that
case you don't actually gain anything.
The journal isn't really the issue, as /var is generally read-only
initially anyway.

(and yeah, I am pretty sure initrd should run systemd – which implies
running journald too – for reasons described above: you want to keep
the differences minimal)

My maingoal here is really about having read-access to things, and
being able to schedule stuff based on configuration and existance of
things, even if that stuff cannot be written to yet. If /var is
mounted this late it makes things a lot more complex.

Lennart
--
Lennart Poettering, Red Hat
Reindl Harald
2016-02-13 12:44:05 UTC
Permalink
Post by Lennart Poettering
My maingoal here is really about having read-access to things, and
being able to schedule stuff based on configuration and existance of
things, even if that stuff cannot be written to yet. If /var is
mounted this late it makes things a lot more complex.
it's still unclear *what* that chnage means for setups like over the
long and it makes a lot of sense to have /var/log not on the sysroot for
as example inbound spamfilters logging a lot to prevent fill the rootfs

[***@mail-gw:~]$ cat /etc/fstab | grep log
UUID=a8fc620d-8046-47a3-8b63-102c525ce5e8 /var/log ext4 defaults,
noexec 0 1
Christian Seiler
2016-02-13 13:17:42 UTC
Permalink
UUID=a8fc620d-8046-47a3-8b63-102c525ce5e8 /var/log ext4 defaults, noexec 0 1
To be fair to Lennart: your specific use case, if /var/log is just a
separate partition, will work perfectly fine even with Lennart's
change, because mounting a partition on a local storage device using
the UUID is already supported by initramfs implementations (see the
/usr case).

My objection to the change is about more complicated storage setups,
where one would need to put in a lot of work to be rid of limitations
we all have accepted for / and /usr.

Regards,
Christian
Reindl Harald
2016-02-13 13:46:47 UTC
Permalink
Post by Christian Seiler
UUID=a8fc620d-8046-47a3-8b63-102c525ce5e8 /var/log ext4 defaults, noexec 0 1
To be fair to Lennart: your specific use case, if /var/log is just a
separate partition, will work perfectly fine even with Lennart's
change, because mounting a partition on a local storage device using
the UUID is already supported by initramfs implementations (see the
/usr case)
that's what i wanted to have finally confirmed
Christian Seiler
2016-02-13 13:12:52 UTC
Permalink
Post by Lennart Poettering
Post by Christian Seiler
Post by Lennart Poettering
Post by Simon McVittie
Post by Lennart Poettering
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 don't think /var is really the same thing as /usr: for a start, it has
to be read/write, whereas /usr and / can be read-only for at least the
early stages of boot.
On stateless systems with a read-only / and /etc, requiring /var to be
mounted from the initramfs would mean that the mechanism for setting up
/var (NFS or tmpfs or whatever) would have to move into the
initramfs.
Since initrds tend to cover root-on-nfs, root-on-iscsi and so on
anyway, that sounds like no change in behaviour really..
Well, kind-of. The root-on-nfs and root-on-iscsi are dumbed-down
versions of what's possible once a system is booted.
Well, to my understanding dracut and stuff makes pretty much all
storage tech that is available during the normal system also available
in the initrd, with the same software, to make sure testing stays
managable.
Ok, so I just checked.

So the very last version of dracut (released 3 months ago) supports
starting iscsid in the initramfs, older versions do not - and only
if systemd is installed in the initramfs image. If there's no
systemd in the initramfs or an older version is used, dracut uses
the iscsistart binary as I explained. So support for this is very,
very new.

NFS (latest dracut git master): idmapping for NFSv4 is supported to
some extent, but there are a lot of assumptions going in: it assumes
that nsswitch is used for idmapping (which is probably the most
common case on clients, but it need not be the only possibility), it
tries to install all nsswitch modules found in /etc/nsswitch.conf,
but doesn't know anything about their configuration.

What's not supported at all: NFS with Kerberos support. I should note
note that NFS w/ Kerberos doesn't work out of the box for /var on a
running system either, because you still need to fetch a Kerberos
ticket for all the system users that access /var, but it's relatively
easy to set something like that up, because you just need to write
a simple systemd service for that and run it at boot - which most
admins will be able to do - modifying the initramfs is a lot more
complicated (especially because the documentation is sparse and the
criticism of many people that initramfs are black magic is there for
a reason).

So basically: it's probably going to work in many cases as long as
you don't want a Kerberized setup, but not everything will work out
of the box, even if you don't use Kerberos.

NBD: dracut (current git master) currently doesn't even support
/usr on nbd if / isn't on it (and even then only if on the same
device).

And then there are still other setups that I had mentioned.
DRBD with cluster filesystem: not supported in initramfs. sshfs:
doesn't work in initramfs. FUSE filesystems in general: I only
know that some people have experimented with zfs-fuse for the
rootfs, and it was very fiddly at best from what I remember.
And while most people who want to use ZFS on Linux nowadays use
the kernel module (where binaries can't be distributed for legal
reasons), other FUSE filesystems still have the same issue. The
problem is that storage is complicated. You need to special-case
each different storage type and add specific code to make that
work in the initramfs. If you look at the dracut source code,
every different storage solution is special-cased. You need to
make sure that the programs required for that storage work in an
initramfs environment and can either terminated before
switch_root and then restarted in the running system, or
alternatively support being kept around during switch_root. You
need to have glue code that copies the right files into the
initramfs.

For rootfs there are certain limitations that have been widely
accepted, but if you now start to say that lots of common mount
points, especially some parts of /var, to be required to be
mounted in the initramfs, you'll make life a lot more complicated
for a lot of people.

A _lot_ of different projects will have to make sure that their
software now works in an initramfs context, even if it was never
intended to be used for the root filesystem. That's a lot of
work for other people, especially since coordination between
different projects is required, just to save yourself from a bit
of complexity in systemd.
Post by Lennart Poettering
I think you are extrapolating from limitations of one specific initrd
implementation, no?
No. dracut has had some improvements in this regard very recently,
but the main point that more complicated storage setups are not
automatically supported in initramfs still stands.
Post by Lennart Poettering
My maingoal here is really about having read-access to things, and
being able to schedule stuff based on configuration and existance of
things, even if that stuff cannot be written to yet. If /var is
mounted this late it makes things a lot more complex.
So could you perhaps provide a list of things you need *exactly*
and what for? Because maybe there's a better solution for that
than requiring /var to be present at switch_root time.

Regards,
Christian
Mantas Mikulėnas
2016-02-13 13:28:14 UTC
Permalink
Post by Lennart Poettering
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 didn't care about /usr, I always thought mounting it from the initrd is
fine. (Especially since most people I've seen only have the separate
filesystem directly at /usr, not separate ones at /usr/bin, /usr/lib, etc.)

But doing that with more and more filesystems, especially /var, somewhat
feels like going backwards from what systemd itself was trying to push
once, doesn't it? It used to be "sysv's mount -a is inflexible and you
should specify correct dependencies and use RequiresMountsFor" and all
that. Now we're going back to "specifying correct dependencies is a pain
and you should mount everything at once before starting any services"...

It's also unclear what precisely needs to be present, since people *do*
often have mountpoints for individual subdirectories under /var, e.g. I've
seen /var/log and /var/lib/mysql. So, for example, will systemd require
/var/lib/mysql to be mounted by my initramfs, even if mysql.service already
takes care of it? Or will it only require /var/lib/systemd or /var/log? How
is one supposed to know?
--
Mantas Mikulėnas <***@gmail.com>
Ahmed S. Darwish
2016-02-18 18:34:03 UTC
Permalink
Hi :-)
Post by Lennart Poettering
Heya!
...
Post by Lennart Poettering
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.
What about fastboot, < 1 second, _initrd-less_, embedded systems
that usually mount root read-only, while mounting /var as a tmpfs?

Does any solution exist for these systems if such changes are
applied?

Thanks a lot,
--
Darwish
http://darwish.chasingpointers.com
Mike Gilbert
2016-02-19 01:33:06 UTC
Permalink
On Thu, Feb 11, 2016 at 12:06 PM, Lennart Poettering
Post by Lennart Poettering
1) systemd-initctl (i.e. the /dev/initctl SysV compat support). Last
time Debian was still using that, maybe this changed now?
Gentoo allows switching between systemd and openrc (sysvinit) at boot
time, and will continue to do so for the foreseeable future.

By default, sysvinit owns /sbin/initctl, /sbin/halt, etc. Users may
swap these to symlinks to systemd and systemctl by setting a USE flag,
but if they do so they knowingly lose the ability to switch back to
openrc without a rebuild of the affected packages.

I would like to selfishly request that you keep this interface around
as long as possible; if you remove it I will have to come up with some
replacement.
Lennart Poettering
2016-02-19 12:22:12 UTC
Permalink
Post by Mike Gilbert
On Thu, Feb 11, 2016 at 12:06 PM, Lennart Poettering
Post by Lennart Poettering
1) systemd-initctl (i.e. the /dev/initctl SysV compat support). Last
time Debian was still using that, maybe this changed now?
Gentoo allows switching between systemd and openrc (sysvinit) at boot
time, and will continue to do so for the foreseeable future.
By default, sysvinit owns /sbin/initctl, /sbin/halt, etc. Users may
swap these to symlinks to systemd and systemctl by setting a USE flag,
but if they do so they knowingly lose the ability to switch back to
openrc without a rebuild of the affected packages.
I would like to selfishly request that you keep this interface around
as long as possible; if you remove it I will have to come up with some
replacement.
So here's probably what is going to happen.

The initctl support in systemctl will be dropped and replaced by some
callout script support. i.e. when you want to use systemctl to reboot
a sysvinit system, then systemctl won't do that anymore, but it will
invoke some shell script as a fallback, where distros can place the
necessary commands if they care about this. This follows how we do
sysv script enable/disable handling (i.e. the chkconfig hookup).

We'll eventually kill /dev/initctl support. Distros should really find
their own replacement for this. They can either take the current code,
build it externally, or write some new code. You might be able to
implement this in a carefully prepared shell script that invokes
busctl to do the reboot. You could use "dd" to read the initreq
structure from STDIN with the precise size, then figure out which kind
of request it is (again, by using dd to extract the four bytes
starting at index 4 of that request structure) and then simply execute
the right busctl command to poweroff/reboot/...

I'll not drop this right-away, but let's say in 6month or so this will
go away. This should be an ample heads-up to find a replacement and
prepare for this.

Thanks,

Lennart
--
Lennart Poettering, Red Hat
Mike Gilbert
2016-02-25 03:42:53 UTC
Permalink
On Fri, Feb 19, 2016 at 7:22 AM, Lennart Poettering
Post by Lennart Poettering
Post by Mike Gilbert
On Thu, Feb 11, 2016 at 12:06 PM, Lennart Poettering
Post by Lennart Poettering
1) systemd-initctl (i.e. the /dev/initctl SysV compat support). Last
time Debian was still using that, maybe this changed now?
Gentoo allows switching between systemd and openrc (sysvinit) at boot
time, and will continue to do so for the foreseeable future.
By default, sysvinit owns /sbin/initctl, /sbin/halt, etc. Users may
swap these to symlinks to systemd and systemctl by setting a USE flag,
but if they do so they knowingly lose the ability to switch back to
openrc without a rebuild of the affected packages.
I would like to selfishly request that you keep this interface around
as long as possible; if you remove it I will have to come up with some
replacement.
So here's probably what is going to happen.
The initctl support in systemctl will be dropped and replaced by some
callout script support. i.e. when you want to use systemctl to reboot
a sysvinit system, then systemctl won't do that anymore, but it will
invoke some shell script as a fallback, where distros can place the
necessary commands if they care about this. This follows how we do
sysv script enable/disable handling (i.e. the chkconfig hookup).
We'll eventually kill /dev/initctl support. Distros should really find
their own replacement for this. They can either take the current code,
build it externally, or write some new code. You might be able to
implement this in a carefully prepared shell script that invokes
busctl to do the reboot. You could use "dd" to read the initreq
structure from STDIN with the precise size, then figure out which kind
of request it is (again, by using dd to extract the four bytes
starting at index 4 of that request structure) and then simply execute
the right busctl command to poweroff/reboot/...
I'll not drop this right-away, but let's say in 6month or so this will
go away. This should be an ample heads-up to find a replacement and
prepare for this.
The existing systemd-initctl (/dev/initctl) interface works quite
nicely, so I will probably end up extracting it from systemd when you
drop it, or just building/installing it from an older systemd tarball.
No need to reinvent the wheel.

Thanks for the response.
Mike Gilbert
2016-04-01 20:11:05 UTC
Permalink
Post by Mike Gilbert
On Fri, Feb 19, 2016 at 7:22 AM, Lennart Poettering
Post by Lennart Poettering
Post by Mike Gilbert
On Thu, Feb 11, 2016 at 12:06 PM, Lennart Poettering
Post by Lennart Poettering
1) systemd-initctl (i.e. the /dev/initctl SysV compat support). Last
time Debian was still using that, maybe this changed now?
Gentoo allows switching between systemd and openrc (sysvinit) at boot
time, and will continue to do so for the foreseeable future.
By default, sysvinit owns /sbin/initctl, /sbin/halt, etc. Users may
swap these to symlinks to systemd and systemctl by setting a USE flag,
but if they do so they knowingly lose the ability to switch back to
openrc without a rebuild of the affected packages.
I would like to selfishly request that you keep this interface around
as long as possible; if you remove it I will have to come up with some
replacement.
So here's probably what is going to happen.
The initctl support in systemctl will be dropped and replaced by some
callout script support. i.e. when you want to use systemctl to reboot
a sysvinit system, then systemctl won't do that anymore, but it will
invoke some shell script as a fallback, where distros can place the
necessary commands if they care about this. This follows how we do
sysv script enable/disable handling (i.e. the chkconfig hookup).
We'll eventually kill /dev/initctl support. Distros should really find
their own replacement for this. They can either take the current code,
build it externally, or write some new code. You might be able to
implement this in a carefully prepared shell script that invokes
busctl to do the reboot. You could use "dd" to read the initreq
structure from STDIN with the precise size, then figure out which kind
of request it is (again, by using dd to extract the four bytes
starting at index 4 of that request structure) and then simply execute
the right busctl command to poweroff/reboot/...
I'll not drop this right-away, but let's say in 6month or so this will
go away. This should be an ample heads-up to find a replacement and
prepare for this.
The existing systemd-initctl (/dev/initctl) interface works quite
nicely, so I will probably end up extracting it from systemd when you
drop it, or just building/installing it from an older systemd tarball.
No need to reinvent the wheel.
Thanks for the response.
Ripping systemd-initctl out of the systemd source tree was more
difficult than I anticipated. Instead, I rewrote a simpler version.
The code is on bitbucket.

https://bitbucket.org/floppym/gentoo-systemd-initctl/src
Daniel Mack
2016-04-15 10:42:06 UTC
Permalink
Hi Mike,
Post by Mike Gilbert
Post by Mike Gilbert
The existing systemd-initctl (/dev/initctl) interface works quite
nicely, so I will probably end up extracting it from systemd when you
drop it, or just building/installing it from an older systemd tarball.
No need to reinvent the wheel.
Thanks for the response.
Ripping systemd-initctl out of the systemd source tree was more
difficult than I anticipated. Instead, I rewrote a simpler version.
The code is on bitbucket.
https://bitbucket.org/floppym/gentoo-systemd-initctl/src
Nice, thanks for working on this! What's still missing in that is the
other side, the client that talks to the initctl socket. I have patches
to remove the initctl bits from the systemd repo, and add a callout from
systemctl to binaries in a directory. The initctl client would live in
that directory, and be automatically called as a fallback then.

Would you be okay with transferring this repository to the systemd
organization on GitHub?

Michael, would you be fine with integrating this downstream to not lose
any compat?


Thanks,
Daniel
Mike Gilbert
2016-04-15 13:55:45 UTC
Permalink
Post by Daniel Mack
Nice, thanks for working on this! What's still missing in that is the
other side, the client that talks to the initctl socket. I have patches
to remove the initctl bits from the systemd repo, and add a callout from
systemctl to binaries in a directory. The initctl client would live in
that directory, and be automatically called as a fallback then.
I'm not sure what you mean by this; the de-facto "initctl client" is
the telinit binary from sysvinit. There should be no need to
re-implement that.

Are you referring to some other interface? Does upstart do something similar?
Post by Daniel Mack
Would you be okay with transferring this repository to the systemd
organization on GitHub?
I'm happy to move it if others want to utilize it. I will need someone
to set me up with access to push the code, however.
Daniel Mack
2016-04-15 15:43:06 UTC
Permalink
Post by Mike Gilbert
Post by Daniel Mack
Nice, thanks for working on this! What's still missing in that is the
other side, the client that talks to the initctl socket. I have patches
to remove the initctl bits from the systemd repo, and add a callout from
systemctl to binaries in a directory. The initctl client would live in
that directory, and be automatically called as a fallback then.
I'm not sure what you mean by this; the de-facto "initctl client" is
the telinit binary from sysvinit. There should be no need to
re-implement that.
Are you referring to some other interface? Does upstart do something similar?
I'm referring to systemctl's own implementation, which is used when PID1
is not systemd. See talk_initctl() in systemctl.c. I'd move that out to
an own binary, and add a generic callout mechanism to systemctl (which I
already did).

What also missing in your repository is the manpage and a README.
Post by Mike Gilbert
Post by Daniel Mack
Would you be okay with transferring this repository to the systemd
organization on GitHub?
I'm happy to move it if others want to utilize it. I will need someone
to set me up with access to push the code, however.
Great, will do. What's your GitHub handle?


Thanks,
Daniel
Mike Gilbert
2016-04-15 17:03:08 UTC
Permalink
Post by Daniel Mack
Post by Mike Gilbert
Post by Daniel Mack
Nice, thanks for working on this! What's still missing in that is the
other side, the client that talks to the initctl socket. I have patches
to remove the initctl bits from the systemd repo, and add a callout from
systemctl to binaries in a directory. The initctl client would live in
that directory, and be automatically called as a fallback then.
I'm not sure what you mean by this; the de-facto "initctl client" is
the telinit binary from sysvinit. There should be no need to
re-implement that.
Are you referring to some other interface? Does upstart do something similar?
I'm referring to systemctl's own implementation, which is used when PID1
is not systemd. See talk_initctl() in systemctl.c. I'd move that out to
an own binary, and add a generic callout mechanism to systemctl (which I
already did).
Oh, I see. I had no idea systemctl has such code.
Post by Daniel Mack
What also missing in your repository is the manpage and a README.
Post by Mike Gilbert
Post by Daniel Mack
Would you be okay with transferring this repository to the systemd
organization on GitHub?
I'm happy to move it if others want to utilize it. I will need someone
to set me up with access to push the code, however.
Great, will do. What's your GitHub handle?
I'm floppym on github.
Daniel Mack
2016-04-15 17:33:26 UTC
Permalink
Post by Mike Gilbert
Post by Daniel Mack
Post by Mike Gilbert
I'm happy to move it if others want to utilize it. I will need someone
to set me up with access to push the code, however.
Great, will do. What's your GitHub handle?
I'm floppym on github.
Thanks - you're now the admin of this new repository:

https://github.com/systemd/systemd-initctl/

I'm happy to push the client code there once you migrated the project.


However, I'd still like to have an Ack from Michael Biebl on the
downstream integration of this new repository.


Thanks,
Daniel
Mike Gilbert
2016-04-15 17:55:33 UTC
Permalink
Post by Daniel Mack
Post by Mike Gilbert
Post by Daniel Mack
Post by Mike Gilbert
I'm happy to move it if others want to utilize it. I will need someone
to set me up with access to push the code, however.
Great, will do. What's your GitHub handle?
I'm floppym on github.
https://github.com/systemd/systemd-initctl/
I'm happy to push the client code there once you migrated the project.
The project has been migrated.
Michael Biebl
2016-04-15 20:47:48 UTC
Permalink
Post by Daniel Mack
Post by Mike Gilbert
Post by Daniel Mack
Post by Mike Gilbert
I'm happy to move it if others want to utilize it. I will need someone
to set me up with access to push the code, however.
Great, will do. What's your GitHub handle?
I'm floppym on github.
https://github.com/systemd/systemd-initctl/
I'm happy to push the client code there once you migrated the project.
However, I'd still like to have an Ack from Michael Biebl on the
downstream integration of this new repository.
Well, I guess I already explained our situation. We still need
/dev/initctl in Debian, so ripping that out means we have to provide
that some other way.
I'm not sure if a separate package (large overhead) or simply
reverting the removal is the better option here.

I can only reiterate what I said before: the code is pretty isolated
so I don't see how that causes upstream any maintenance headaches and
I would volunteer to take care of any issues that are caused by that
code.
Personally I would prefer it, if we added a configure switch. This
would be off by default so we wouldn't advertise legacy cruft by
default but it would make it easier for distros which need to maintain
that level of compat support.

Ripping the code out means additional work for us and basically no
gain upstream imho, aside from asthetics.

So from my POV it's a NACK, as I don't see the benefits and only the
additional work.



Regards,
Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
Daniel Mack
2016-04-15 21:00:22 UTC
Permalink
Post by Michael Biebl
Post by Daniel Mack
Post by Mike Gilbert
Post by Daniel Mack
Post by Mike Gilbert
I'm happy to move it if others want to utilize it. I will need someone
to set me up with access to push the code, however.
Great, will do. What's your GitHub handle?
I'm floppym on github.
https://github.com/systemd/systemd-initctl/
I'm happy to push the client code there once you migrated the project.
However, I'd still like to have an Ack from Michael Biebl on the
downstream integration of this new repository.
Well, I guess I already explained our situation. We still need
/dev/initctl in Debian, so ripping that out means we have to provide
that some other way.
I'm not sure if a separate package (large overhead) or simply
reverting the removal is the better option here.
Including the built results of systemd-initctl into your .deb packet is
not a solution? Making that an extra package causes too much trouble, I
totally agree.
Post by Michael Biebl
I can only reiterate what I said before: the code is pretty isolated
so I don't see how that causes upstream any maintenance headaches and
I would volunteer to take care of any issues that are caused by that
code.
Personally I would prefer it, if we added a configure switch. This
would be off by default so we wouldn't advertise legacy cruft by
default but it would make it easier for distros which need to maintain
that level of compat support.
This is an exercise in making the code base smaller and dropping support
for some legacy, while still keeping support around via external
packages. And initctl is a low-hanging fruit, hence the idea.


Thanks,
Daniel
Daniel Mack
2016-04-26 15:28:34 UTC
Permalink
Hi Michael,
Post by Daniel Mack
Including the built results of systemd-initctl into your .deb packet is
not a solution? Making that an extra package causes too much trouble, I
totally agree.
Did you further think about this idea, would that be a solution?


Thanks,
Daniel
Felipe Sateler
2016-04-26 22:29:01 UTC
Permalink
Post by Daniel Mack
Hi Michael,
Post by Daniel Mack
Including the built results of systemd-initctl into your .deb packet is
not a solution? Making that an extra package causes too much trouble, I
totally agree.
Did you further think about this idea, would that be a solution?
I'm not sure I understood your proposal correctly, but each .deb package
is built from one source package. This implies that systemd-initctl
source would have to be somehow imported into the debian systemd source,
and then used to build the shipped binary (ie, not importing the binary
artifacts alone).
--
Saludos,
Felipe Sateler
Daniel Mack
2016-04-27 13:41:21 UTC
Permalink
Post by Felipe Sateler
Post by Daniel Mack
Hi Michael,
Post by Daniel Mack
Including the built results of systemd-initctl into your .deb packet is
not a solution? Making that an extra package causes too much trouble, I
totally agree.
Did you further think about this idea, would that be a solution?
I'm not sure I understood your proposal correctly, but each .deb package
is built from one source package. This implies that systemd-initctl
source would have to be somehow imported into the debian systemd source,
Well, yes. At the same time when downstream patches are applied.
Post by Felipe Sateler
and then used to build the shipped binary (ie, not importing the binary
artifacts alone).
I'm not sure if it's feasible, hence I'm asking.


Daniel
Felipe Sateler
2016-04-27 15:27:41 UTC
Permalink
Post by Daniel Mack
Post by Felipe Sateler
Post by Daniel Mack
Hi Michael,
Post by Daniel Mack
Including the built results of systemd-initctl into your .deb packet is
not a solution? Making that an extra package causes too much trouble, I
totally agree.
Did you further think about this idea, would that be a solution?
I'm not sure I understood your proposal correctly, but each .deb package
is built from one source package. This implies that systemd-initctl
source would have to be somehow imported into the debian systemd source,
Well, yes. At the same time when downstream patches are applied.
Ah, yes, I was confused by your mention of built-results.
Post by Daniel Mack
Post by Felipe Sateler
and then used to build the shipped binary (ie, not importing the binary
artifacts alone).
I'm not sure if it's feasible, hence I'm asking.
It should be doable via either a patch reverting the removal, or a
plain import of the new systemd-initctl sources into the debian.tar.xz
and built in a separate ./configure && make run.
--
Saludos,
Felipe Sateler
Continue reading on narkive:
Loading...