-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 09/22/2014 at 05:39 AM, berenger.mo...@neutralite.org wrote:
> Le 22.09.2014 01:51, John Hasler a écrit : > >> Martin Read writes: >> >>> consolekit is indeed the thing that systemd-logind replaces >>> (and systemd-logind was the reason the maintainers of >>> consolekit stopped maintaining it). >> >> So who is going to step forward and start maintaining it? > > Nobody needs to. systemd-login does *not* depends on the init > system. At no levels. So why should someone have to maintain an > alternative? (well, there are probably tons of reasons, indeed, but > systemd-login being a part of systemd is not a correct one since > login part does not depends on init part.) So I was remembering wrong, and the consolekit angle is apparently a false trail. The problem is not systemd-logind (except from the perspective of people who just don't want any systemd-project code on their systems in the first place), but the dependency from libpam-systemd on systemd-sysv. The fact that we went down that false trail is my fault. The question of "what did these packages do before systemd was available?" was asked, and I provided an incorrect answer, due to my faulty memory. I apologize for that mistake, for the ensuing confusion, and for any associated FUD. Revisiting that question now, it's not quite as simple as "before systemd was available". There are actually three timeframes to consider: 1. Now, with libpam-systemd depending on systemd-sysv (and thus on systemd being PID 1), as a source of cgroups management functionality. 2. The previous timeframe, with libpam-systemd not depending on systemd-sysv, because it provided its own cgroups management. 3. The timeframe preceding that one, with libpam-systemd not available at all. In timeframe 2, the packages in question depended on libpam-systemd, just as they now do. The only difference is that this dependency did not result in an indirect dependency on a particular init system. In timeframe 3, the packages in question did not depend on libpam-systemd, because it was not available. This would have to be confirmed by looking at the individual packages, but I strongly suspect that they simply did not provide the functionality which libpam-systemd now enables. The transition between timeframe 3 and timeframe 2 came when libpam-systemd became available, upstreams added support for the new features it provided, and package dependencies were added appropriately. There's nothing visibly wrong at this stage. The transition between timeframe 2 and timeframe 1 apparently occurred because of a decision by the Linux kernel's cgroups maintainer (or someone with a good claim at authority in that area, anyway) that having multiple programs maintaining multiple cgroups hierarchies - or having multiple programs writing to a single cgroups hierarchy - was bad design, and should no longer be supported at some point. In response to that, the sytemd project removed cgroups management from libpam-systemd, and made libpam-systemd rely on the cgroups management available in systemd-sysv (the PID-1 systemd). As a result, without having changed anything themselves, suddenly all of the packages which had already depended on libpam-systemd now indirectly depended on having systemd be PID 1. What I maintain / argue is that even assuming the kernel's cgroups maintainer's decision was correct (on which I have not yet established any opinion), the correct thing to do in response to that decision would not have been to move all systemd cgroups handling into PID 1 as the most central place where it was already implemented, but to move it all *out* of PID 1 into a separate, standalone daemon. (Or even library, if suitable.) This issue has already been worked around in Debian by the implementation of cgroups support in systemd-shim, using cgmanager. However, that's still a workaround, because the design flaw in having this feature be (primarily) provided by systemd itself is still present. It has been suggested (in filed bugs) that one of the primary consequences of this flaw - the automatic transition to systemd-as-PID-1 when installing packages which depend on libpam-systemd, while not already having systemd-shim installed - be minimized by expressing the dependency on that cgroups management as preferring systemd-shim (the "standalone" implementation) over systemd-sysv (the init-system-dependent implementation). The Debian systemd maintainers have rejected this suggestion, with reasonable arguments (albeit ones which I think are insufficient). There is presently TC discussion going on over whether or not to override that rejection. - -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCgAGBQJUIBkVAAoJEASpNY00KDJr/OoP+gLnnLVjt5JPYTxZbmcq6LQX yNvRhPvvpl240TRq9DigtguLTahdUc1NvGeX17cnO0G4cDLpjoLF3Fv6NdU1iv3d cRjm+++tzgYz8zehNrpXwsMPD4LyUeoexAvUEI2BIUnIQeEAJ2QtNlnbf9Bm9J5l Hp7jTZRjVW91mi0tD80xk2pw5gNcFBbuqKhiu6ve3z/Os64suhE847X46wId8e/b jUY6EFdC4IE9QrFEpl1VXnx3FNXc5iej3dA86i+gbEM6qMn3SWswHKNTZAS1IkR/ MhjxzUcnXcIlWjqGc4ue8p0UbjMP3t+2lnYOuP6/ntTpUuCGmgnX94iWqkkhqNUI 6evzl65QLv2++3v7O9tg5b3mEzmzFzyGFM6rdYZrNfCFiQ+SGaaxJZ9UEaK1XwGG TtGMhshRUy/WcwH1P1RuCN53PW5vsWeY6100i7k9rVbR2GGMTAqLyv6dDYzH7T4C VAZ3+e3SReFvEcy1KpbjIxvJteTuv5BbMWS18Tu0bhMqNuKD/cYT7UI149OI5LrG 81gGXR3gTKecE47rdtJLn1gBol+gVwtqVP2mKCfTKgnPnvVwVkCqhah4MjIBJ6az NntUvC9YDSI+IkOijayZyPnUgKNDUX1fGU3nhnn6YaZG/nk4HEgRr6JhS4TbdnBk g6FXi2K0hmoAM8f+t1Wm =8TuT -----END PGP SIGNATURE----- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54201916.1000...@fastmail.fm
