On 4 January 2014 15:46, Josselin Mouette <j...@debian.org> wrote:
> Le samedi 04 janvier 2014 à 12:47 +0000, Ian Jackson a écrit :
>> Uoti Urpala writes ("Bug#727708: init system discussion status"):
>> > Your earlier wording sounds
>> > like it was talking about the former ("installable") and Ian's proposal
>> > definitely was (explicitly mentioning package fields), but the "fully
>> > working" you use now sounds like it's about the latter.
>>
>> Thanks for pointing this out. My proposal is too weak in this
>> respect. I intended to make the stronger statement.
>
>> I think systemd-ui is part of the systemd init system so falls into
>> the exception. Of course that means that nothing else should depend
>> (functionally or in package dependencies) on it.
>
> There is no way that, for example, some of the GNOME control center
> applets will work at all without systemd.
>
> It is already hard enough to imagine that we would have to ship packages
> without the appropriate dependencies on systemd; expecting them to have
> the same functional coverage without it is simply insane.
>
Can you please explain how a user-level application is dependent on
the system (root) init daemon be systemd-init? Especially since it's
expected to have sysvinit fully functional in Jessie.
Or is this to do with other, inferior to those currently in debian,
ways of e.g. setting up system-wide locales? Or does it depend on
other APIs, which have multiple alternative providers, e.g.
systemd-logind.
With a decision for systemd, are we by transitive means[1] mandating
usage of all other daemons present in the systemd source package and
overruling maintainers of existing functionality with alternative or
compatible APIs[2]?
If we are choosing, non-standartised systemd APIs[3], surely it should
be done as a runtime detection, rather than packaging level
dependency. Because there are multiple providers of the same APIs,
possible at different compatibility levels of systemd versioning and
until upgraded system is rebooted, only some implementations can start
and be already running. Although not supported officially, I do like
that stable can typically be fully functional since the dist-upgrade.
Also it is sad that systemd upstream is actively promoting for
everyone to execute runtime checks of "is systemd-init pid1, and
what's systemd version number", 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. Fedora 19
appears to be packaging patches from v204-stable branch which I can't
find anywhere public. 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). We've had a charming history of doing so with pulseaudio: with
default in 2007 in Fedora, shipped in stable Ubuntu 8.04 LTS in 2008,
where Lennart promote it as stable to Ubuntu Developers at first, and
later claiming that "Ubuntu didn't exactly do a stellar job. They
didn't do their homework." Redhat enterprice linux has shipped it
version 6 - in 2011 it seems. Pulseaudio did turn out ok, although
years later, after extensive usage by real customers base
(unfortunately Ubuntu customers first, and later RedHat's).
Fedora/RPM based distributions are significantly different, thus it is
inevitable that we'll have to maintain a fork of systemd for best
integration into Debian. This does not seem evident from the current
systemd maintainers, which file bugs to disable/remove/override debian
functionality and components with inferior systemd counterparts.
Now the questions is, what will RHELv7 ship? is it v204, v204-stable
(non-public git), v207-stable (non-public git), v208, v208-stable
(non-public git)? And what level of systemd is targetted to be
integrated into jessie?
At the moment RHEL beta 7 has systemd-207 with 95 long patch series.
This looks to me as in-flux state. How is systemd stable maintenance
going to be handled in the future? with redhat subscription?
It seems to me that init component has been extensively reviewed, but
what about other components. Post 204/205, logind appears to require
systemd's api for cgroup management, but the cgroup manager done in
systemd is inferior to all other cgroup management implementations[7].
Are we going to support systemd/logind with alternative (and superior)
cgroups managers, and for example more portable logind with
systemd-shim. Granted in debian we have pleora of Desktop
Environments, Logind Managers, and container/virtualisations solutions
that all work. Some have more or less dependencies. And it appears to
me beneficial for even more things to be enabled, e.g. newer GNOME
with it's dependcies on APIs from some of the bundled
systemd-collection-of-daemons, provided with or without systemd-init
as pid1, or those APIs provided by alternative implementations.
Similarly I do not wish for server/container/virtualisations on Debian
to be worsened by the default set of applications "for GNOME", and
e.g. still allow to use and start containers of any linux
distributions and fully exercise all resource allocations APIs exposed
by the kernel (e.g. cgroupsfs, etc).
Upstream stability guarantees, which are also quite loudly shouted
here, do not appear to be kept. E.g. at the time consolekit -> logind
migration was pitched to DEs, there was no hard cgroups requirement
(it was an optional logind feature) which is now present with post-DEs
migrating to logind. Whilst I partially understand the tarpit of
pre-consolekit problems, how consolekit fixed some of those, and how
logind improved on that; on the other hand, even after porting one of
my upstream projects to logind, I still don't know and understand
logind usefulness on headless/server deployments or the meanings of
the missnamed logind specific variables XDG_VTNR, XDG_SESSION_ID,
XDG_SESSION_PATH, XDG_SEAT[9]. Especially in the light of kdbus
removing per-session dbus and leaving only a per-user dbus. If indeed
systemd's cgroups API is as frozen, as argued by systemd proponents,
I'm worried that debian will be stuck with inferior cgroups support.
Contrasting with upstart, it is shipped in stable and commercially
supported distributions by majority linux vendors [8] and large
corporations (cisco, google, lg, etc.). It's codebase is highly
stable, point-releases / stable branches are created when bug-fixes
are cherrypicked, updates granularity matches 6-monthly ubuntu
releases and there are two or more supported LTS releases for any
given supported debian release. The diff between upstart as packaged
and upstream is minimal, the largest difference is selinux patch
(non-cla patch, carried for a long time and compile time option
enabled by roughly half or more upstart deployments) and the rest are
minor tweaks for integration with debian-like systems (e.g.
initramfs-tools), grand total of less than 175 lines. Oh, and one is
free to use any available cgroups managers and move any processes into
respective cgroups resource group, use bundled systemd-noninit daemons
APIs for the DE of your choice (and given the pleora of gnome2/3 forks
it's evident that GNOME-latest is not a silver bullet for all), etc.
[1] upstream unwilling to support multiple equivalent components &
debian maintainers of systemd willing to keep packaging as close to
upstream as possible: e.g. support for alternative & superior cgroups
management/logind, our support for setting system-wide locales,
integration with binfmt-support etc.
[2] e.g. systemd-shim/logind, pam-xdg-support, etc.
[3] by which i mean for example peer reviewed freedesktop spec of dbus
verses all the ways systemd-kdbus is backwards incompatible &
regressing feature-wise (no per-session dbus, new marshalling, no
activation support, reduced policy support, etc.)
[4] it appears that upstream git is used as packaging basis, instead
of the tarball which has pre-generated documentation and loads of
other files.
[5] Which by the way mostly applies on top of debian packaging - all
but 6 or 7ish.
[6] recall, that redhat & fedora migrated from upstart, non sysvinit.
[7] one is only offered limited resource allocation apis when compared
to cgroupsfs (with or without multiple hierarchy), the Google's
lmctfy, and the cgroupsmanager by hallyn (not sure about the official
name)
[8] and all of them are here to stay for extended periods of time from now
[9] and their leakage to my sbuild logs
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729012
--
Regards,
Dimitri.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
