Re: let's split the systemd binary package
On 25 October 2013 13:13, Simon McVittie <smcv@debian.org> wrote:
> On 25/10/13 11:52, Dmitrijs Ledkovs wrote:
>> - using XDG_* environment variables, instead of LOGIND_* or SYSTEMD_* variables
>
> I assume you mainly mean XDG_RUNTIME_DIR here, since the rest are
> basically user-level rather than system-level.
>
No, I mean:
XDG_VTNR=7
XDG_SESSION_ID=c1
XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session0
XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0
XDG_SEAT=seat0
Above variables are specific to logind and pollute XDG_* namespace.
And well all logged in graphical user sessions evnironment is polute
which leaks everywhere (e.g. sbuild build-logs). Non-graphical
sessions have less variables, but still there shouldn't be any.
XDG_RUNTIME_DIR is absolutely fine as well as all the other variables
defined in the XDG Base Directory Spec
http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
> The point of the XDG_* family of variables is that they're intended to
> be a cross-desktop, multi-implementation standard. I think pam_systemd
> and its communication with systemd-logind might be the only
> implementation of XDG_RUNTIME_DIR we have right now, but there'd be
> nothing to stop someone writing a pam_xdgruntime that did it in-process,
> analogous to pam_mkhomedir.
>
XDG_RUNTIME_DIR has also been implemented by
https://launchpad.net/pam-xdg-support project.
The VTNR, SESSION_ID, SESSION_PATH, SEAT_PATH, SEAT are logind
specific at the moment, no standard published by FreeDesktop, nor has
multiple implementations, which kind of comes from not having a
cross-distro spec in the first place.
> The advantage of XDG_RUNTIME_DIR is that it makes any specification that
> refers to it simpler. For instance, if it had existed all along and been
> a prerequisite for D-Bus, we could say "use the Unix socket
> $XDG_RUNTIME_DIR/dbus/session" rather than "There's a socket somewhere,
> probably in /tmp or something, or it might be abstract, who knows? Use
> $DBUS_SESSION_BUS_ADDRESS to find it, and make sure that variable gets
> set correctly, otherwise you lose".
>
> The disadvantage of XDG_RUNTIME_DIR, which sets it apart from the other
> XDG_* variables, is that there's no good default if it isn't set: it
> requires that something on the system creates a suitable directory,
> potentially requiring privileges to do so. In contrast,
> XDG_{CACHE,DATA,CONFIG}_* can all have sensible defaults (a
> dot-directory in $HOME, which applications can create when needed).
>
> The reason that XDG_RUNTIME_DIR potentially requires privileges is that
> unprivileged users can't guarantee to be able to create a directory on a
> fully-featured local Unix filesystem with Unix sockets, fifos, atomic
> rename, etc. (as opposed to NFS or VFAT or something similarly limited).
> systemd-logind guarantees that by using a tmpfs, which has those features.
>
I think above is unnecessory. I am well aware of RUNTIME_DIR benefits
and that's not the issue I am raising.
>> I think from above points you can see, that it's not unreasonable to
>> easily mistake that systemd brings logind, instead of "logind is part
>> of the systemd software collection" & that all of "the systemd daemon
>> collection" somehow is required / endorsed by FreeDesktop project.
>
> To clarify, freedesktop.org is (at least) two things:
>
> * specifications: a set of desktop-agnostic would-be-standards for
> "APIs" that desktop environments benefit from sharing (window manager X
> property conventions, .desktop files to describe applications, XDG_*
> search paths for data/configuration, etc.). I suppose the ideal for
> these could be expressed as "not having a competing standard because
> nobody needs one".
>
Sure, where is the spec for logind specific variables? Or
implementations that is desktop-agnostic, or more specifically for
Debian - OS/kernel agnostic.
> * software: a hosting site for projects that aspire to be used in a
> cross-desktop way, analogous to a more focused
> Sourceforge/Github/Alioth. Some of these remain current (systemd,
> Telepathy, D-Bus, LibreOffice, Xorg, lightdm), some get deprecated as
> their authors realize they had design issues (ConsoleKit, HAL), some
> never really got wide adoption in the first place (Ytstenut, APOC,
> arguably Geoclue). Many of these projects have long-term competitors
> (systemd/Upstart/OpenRC/etc., NM/wicd/ConnMan/etc.,
> lightdm/gdm/kdm/etc., Xorg/Wayland) and that's fine.
>
> With hindsight, it would have probably been better off with two separate
> names for those things, but it's rather too late.
>
yeah, it's a hosting service for a clique of developers, not quite
public open source hosting site (e.g. github, bitbucket, sourceforge,
etc). meh, I don't really care where stuff is hosted.
> Things named with "XDG" are mostly the specification side. Things that
apart from logind it seems....
> have their own "brand name" are mostly the software side (e.g. they're
> called Telepathy and lightdm, not "Freedesktop Communications" and "XDG
> Display Manager" or something).
>
> Some of the software projects (e.g. systemd, Telepathy) also promote
> their own API specifications which are intended to be implemented by
> third parties (e.g. systemd's /etc/machine-id and /etc/os-release,
> Telepathy's clients and connection managers).
>
>> I don't know if it works on older kernels and/or without cgroups
>> and/or how portable /just/ logind is, or other individual daemons in
>> "the systemd daemon collection".
>
> I don't think systemd-as-init requires any of the other daemons (pid 1
> requiring other processes has chicken-and-egg problems!), but (the
> systemd implementations of) some of the other daemons require
> systemd-as-init. You might have been assuming it to be the other way round?
>
> In practice, I think the situation is something like:
>
> * hostnamed and timedated probably work fine without systemd-as-init, or
> if not, they'd be relatively straightforward to fork or reimplement (I
> believe the OpenRC people already reimplemented them?)
>
See systemd package in ubuntu, it actually packages some of the above
"systemd collection of daemons" without "the init daemon", but this is
rather out of necessity than by choice. And it'd rather not see Debian
adopt some of those daemons, due to questionable benefit they bring.
> * logind (<= 204) works without systemd-as-init
>
> * logind (>= 205) requires systemd-as-init, which it uses to manage cgroups
>
Oh, yeah. With added benefit of killing all processes in the session's
cgroup on logout. Good bye, detached screen / irc. Thanks, but no
thanks.
Well, it's clear where to fork logind then, and package it as a
separate source package.
Regards,
Dmitrijs.
Reply to: