Bug#727708: init system discussion status
On Sat, Jan 04, 2014 at 06:59:46PM +0000, Dimitri John Ledkov wrote:
> Also it is sad that systemd upstream is actively promoting for
> everyone to execute runtime checks of is systemd-init pid1,...
This is done public systemd libraries to become NOPs if not running on
or not compiled for systemd, to make it easier to integrate
systemd-related functionality in programs portable to other
environments. Full original functionality can be always trivially
restored.
Built-in systemd components do no such checks, and generally are
written with the assumption that they are using the same systemd
versions. (What I'm saying is quite inprecise, but because it's not
the main point, I don't want to go into details.)
> what's systemd version number",
I'm not aware of any such checks.
> granted Martin Pitt did identify this
> problem and fixed majority of opensource projects to check for the
> requested/required functionality, instead of arbitrary transitive
> checks of pid1. This in part enables to run systemd-logind without
> systemd-init as pid 1.
>
> Also which upstream are staying with? systemd upstream git history[4]
> has only one branch, which is linear with linear version number
> increments, without any stable release branches or other indications
> of which patches are stable (or possibly security) bugfixes.
git notes are used to mark backport-worthy commits. See
http://lists.freedesktop.org/archives/systemd-devel/2013-September/013188.html.
We currently mark patches as bugfixes (which includes fixes for bugs
present in the latest release, but not those introduced later),
or documentation and performance improvements.
> Fedora 19 appears to be packaging patches from v204-stable branch
> which I can't find anywhere public.
It's my private branch I generate Fedora packages from [1]. It's the
same content as in Fedora git repos [2], but in a more convenient form
for me. I talked with other systemd maintainers in Fedora about making
it more official and public, but we haven't found the time to do it
yet. If it was to be useful to other people, it can certainly be done.
[1] http://kawka.in.waw.pl/git/systemd/
[2] http://cgit.freedesktop.org/systemd/systemd/
> Thankfully it's not a single giant patch as it's
> done by RedHat for their kernels, but actually git am formatted series
> of 116 patches[5].
>
> The diffstat between:
> - debian package and git v204 checkout is: 44 files, 246 +, 566 -
> - fedora 19-204 and v204 tarball: 102 files, 11368 +, 1366 -
> - rhel 7-beta-src-iso and v207 tarball: 133 files changed, 2364
> insertions(+), 1686 deletions(-)
>
> Which is a significant chunk of fixes. Looking at some of them, they
> are true gems like "don't truncate and loose multiline syslog
> messages" which is not fixed in Debian at the moment. Can we please
> not have journald by default in jessie, cause I don't want my syslog
> truncated?!
>
> In my opinion it is unwise to ship something into stable, ahead of
> upstream doing so for their support customers (RedHat Enterprise
> Linux).
I think you're overestimating the (direct) influence of Redhat on
system upstream bug fixes. There are patches ("don't truncate and
loose multiline..." being one of them) done as a result of a bug
reported in RHEL, but their number is insignificant compared to the
number of bugs reported and fixed in Fedora, the upstream bugtracker
and other distro's bugtrackers. Actually Debian is suffering here
becuase of the large version gap to current upstream. It makes it
much harder to reproduce bugs, and if fixes are done, additional
work is required in backporting. After various codebase cleanups
and the the post-208 rewrite to use libsystemd-bus in systemd
components, any patch which touch dbus codepaths has to be rewritten
rather than cherry-picked to such old versions.
Zbyszek
Reply to: