On 4 January 2014 23:16, Zbigniew Jędrzejewski-Szmek <zbys...@in.waw.pl> wrote: > 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.) >
So components inside systemd-source tree do not follow what's advised to all other projects: e.g. link or statically include sd_* helper files, and perform runtime checks? How much functionality / api is exported by libraries/dbus of systemd to move components out of the systemd tree and into separate projects. Or, what's more interesting, projects external to systemd integrating on the same level. E.g. in upstart, all common code is factored into stable-api/abi libnih, which is then free to use by anyone (e.g. event bridges, mount helpers, etc.) and all communication to/from upstart is exported via dbus IPC (on private socket or systemd dbus). If code-sharing is only happening by being part of the systemd codebase, that also increases barrier of entry. E.g. it would be benefitial for systemd to support hallyn's cgroupmanager (which can be used standalone or not). >> what's systemd version number", > I'm not aware of any such checks. > I'll find references, but I believe some components in KDE starting doing so upstream which has been reported to me from ProjectNeon/Kubuntu. I'll follow up more on that. Again, not sure if this is lack or shared library for logind support, but a lot of projects were using sd_booted() (pid1 init check) instead of checking for logind e.g. (access("/run/systemd/seats/", F_OK) >= 0) It would be easier if software that integrates with individual services was doing imperical checks of the services it uses, or better gracefully fail-over at runtime if those fail (e.g. over dbus). Also logind seat management seems to use "systemd" names instead of XDG-names (as done in other places) or like a generic name "logind". Looks untidy, and making DEs claim they "support or require" systemd-init, when infact they mean logind. >> 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. > Thank you for this link, I was not aware of this policy. This is the first time i see git-notes used for tracking bugs needed for stable/security/documentation, and it was hard for me to find. Does also mean such stable maintenance only started in September 2013? Or some other scheme used before that? Current debian version of systemd is v204, tagged in May 2013. >> 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. > Thank you for pointing out where it is. Maybe add a URL in the spec file pointing to where it is? Cause I've search hard and didn't manage to find where it's maintained. (or push a mirror to github systemd projects or some other place if you require team commit access) I guess that also makes the RHEL patch series based on yours/fedora releases. Are there changes that are in RHEL7 and not in fedora, your fork, and upstream? Debian SytemD maintainers, has the ~116 fedora's stable fixes patch series been reviewed and decided to not be applied? What about stable branches from other distributions, have those been investigated? > [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. > This confirms that systemd is not generic across all upstreams and all distributions, and everyone is maintaining their own (in part influenced by release cadence, and well distro-specific integration) Having git repos, or even distro specific branches on Freedesktop.org would help. Since well, it's suppose to be a cross distro collaboration projects. I see little point in each distribution redoing it's own stable maintainance. A lot of debian-specific patches would be gone, if systemd did look up daemons based on path instead of hardcoded paths, but alas that has been rejected upstream. I don't see why we should be pointlessly moving our binaries around, or spend time patching all unit files (which i guess would then also be claimed as "not supported" by lennart). This diminishes in my view that systemd is a coherent / all-unifying cathedral, suitable as-is to all distributions. I am sorry for overestimation, my biggest worry is RHEL customer bugs and their fixes that are yet to come once systemd is used by those deployments. post-208 rewrite, is interesting, burning bridges with dbus? no freedesktop spec, making a dbus-like implementation which is entirely unportable to other operating systems (BSD, Mac OS X, Windows) makes it entirely unattractive to a lot of cross-platform toolkits like Qt or projects that currently do support those platforms. Standardizing on a toolkit/ecosystem marshaling (GVariant), despite not being political, looks odd from cross-platform point of view. Does that also mean that projects linking against libdbus1 cannot talk to systemd components native, without compat translator running on the systemd side? I guess I have to now study kdbus more, since once again it's pulled into systemd software collection without real need to do so. There I was to think it will just be a bi-directional async IPC method to talk to the kernel, instead of e.g. using syscalls / uevents. -- Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbhluhkby6d5osuxy7cy6qoqokmfmayv3ll2os4hojzpq_...@mail.gmail.com