Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
> "Michael" == Michael Biebl writes: Michael> On Wed, 30 Oct 2019 13:22:14 + Ian Jackson Michael> wrote: >> The bulk of the bug is a discussion about the general approach to >> allowing Debian users to choose between systemd and elogind (and, >> therefore, allowing them to run desktoppy kind of software >> without systemd). As discussed it seems that this C/R/P is >> needed to implement the approach which was agreed between the >> elogind and systemd maintainers. Michael> I very much disagree with this summary. Michael> In [1] I clearly expressed that I did not like this Michael> approach of having a libelogind0 which replaces Michael> libsystemd0. That's actually not how I read that discussion. I read you as grumblingly accepting the necessity of libelogind0 after Mark explained that it was necessary because of the upstream design. I suspect I'm not the only one who honestly read what you said as accepting elogind0 even though it was not your preference. Michael> I think the best option is still the one I outlined in [1], Michael> i.e. getting rid of libelogind0 completely in Debian and Michael> simply ensure that elogind works in combination with Michael> libsystemd0. That's inconsistent with the design of elogind. Mark explored doing that in this bug and outlined why that doesn't work. Summarizing for those less familiar with libsystemd0 than Michael: libsystemd0 splits its interface to systemd across a number of things. A lot of it is in a dbus API. However, it also assumes a certain structure of how cgroups are layed out. Elogind does implement the dbus APIs in question. However elogind lays out cgroups differently. So key functionality does not actually work if you use libsystemd0 iwth elogind. Asking the Debian elogind maintainer to redesign elogind seems like kind of a tall ask. I agree that using libsystemd0 only would be a great option *if it worked*
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
On Wed, 30 Oct 2019 13:22:14 + Ian Jackson wrote: > The bulk of the bug is a discussion about the general approach to > allowing Debian users to choose between systemd and elogind (and, > therefore, allowing them to run desktoppy kind of software without > systemd). As discussed it seems that this C/R/P is needed to > implement the approach which was agreed between the elogind and > systemd maintainers. I very much disagree with this summary. In [1] I clearly expressed that I did not like this approach of having a libelogind0 which replaces libsystemd0. My feedback was ignored though, at which point I stopped engaging further. And since the fallout from the decision to go with this approach (despite my recommendation not to) was so tiresome and caused so much friction, this will most likely be my only message regarding this topic. > I think that it is appropriate that, if possible, the approach taken > should be one that is agreeable to both sets of maintainers. That > makes for the least interpersonal friction (and of course the > respective sets of maintainers are best placed to foresee issues and > judge the merits and (in)elegance of possible approaches). > > So my starting point is that it doesn't seem to me to have been > particularly fruitful to reopen this decision via this bug in this > way. But in any case, the decision has been discussed at some length > here. It doesn't appear that other options are better. I think the best option is still the one I outlined in [1], i.e. getting rid of libelogind0 completely in Debian and simply ensure that elogind works in combination with libsystemd0. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923244#10 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
Control: close -1 Hi. I have been asked to take a look at this bug. I've reviewed the bug log and tried to identify what the issues are that this bug is about. The title is an objection to the Conflicts/Replaces/Provides. I confess I found the bug log rather diffuse. Many different people have contributed a variety of material and it is sometimes difficult to pin down particular problems. In terms of actual malfunctions caused by this set of package relationships, digging through the bugs I found references to these: #934132 Unblock request related to buster, no longer relevant but I looked through it to try to understand the underlying issues. #935910 "apt: Should be less tolerant of dpkg errors..." This is now fixed in apt, in bullseye. #934491 The corresponding blocking bug in elogind. This represents the fact that elogind should not migrate to bullseye until #935910 had been fixed or avoided. #934491 is itself RC. It seems most convenient to deal with that separately, in its own bug; so I don't think that is an issue that should be seen as part of this bug. #935304 is mentioned, but it is related to the libpam-systemd dependency and seems not really related to this bug. The bulk of the bug is a discussion about the general approach to allowing Debian users to choose between systemd and elogind (and, therefore, allowing them to run desktoppy kind of software without systemd). As discussed it seems that this C/R/P is needed to implement the approach which was agreed between the elogind and systemd maintainers. I think that it is appropriate that, if possible, the approach taken should be one that is agreeable to both sets of maintainers. That makes for the least interpersonal friction (and of course the respective sets of maintainers are best placed to foresee issues and judge the merits and (in)elegance of possible approaches). So my starting point is that it doesn't seem to me to have been particularly fruitful to reopen this decision via this bug in this way. But in any case, the decision has been discussed at some length here. It doesn't appear that other options are better. The submitter was asked to state any specific concerns. In response: | So one thing I think we should ensure is we don't end up | uninstalling systemd without an explicit user choice. But, the maintainer reports results of experiments, in message #236, which show that that is already the case. | So I am not sure any changes are required in order to enforce explicit | instruction before attempting removal of systemd. | | Is this sufficient? There hasn't been a reply to that. So I think all of the concrete issues or concerns raised here in this bug have been either recorded more conveniently in other bugs, or resolved - whether that resolution was by fixing bugs, or by verifying that the posited misbehaviour does not occur. It seems to me therefore that this bug ought to be closed. Everything in it has been dealt with, one way or another. If there are any remaining particular, specific, issues or problems, it would probably be most convenient if they were filed as individual bugs. That would let us get to grips with them properly. Thanks, Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
I have been reading on this bug for a while now. On Tue, Sep 24, 2019 at 07:28:29AM +0800, Ian Campbell wrote: > Would it be any help at all of the "dbus client-ish" bits and the > "direct API-ish" bits of the two libraries were split up into two > separate libraries? i.e. would that allow the c/r/p replacement of one > of the two libraries (AIUI the API one is the more problematic) to be > pushed further up the dependency stack? > > (my impression is no, but I thought I'd ask) > > > The only way I have got all of these components to work together on an > > elogind > > systemd is to ensure everything uses libelogind0. > > Has anyone investigated late dynamic binding using a stub library which > merely determines which init is running and then dlopens the > appropriate libsystemd0 of libelogind0 library and forwards the calls > to it? > [...] While this would be a possible approach, this would also require that all applications currently linking with libsystemd need to link with something different, e.g liblogind. I think there was already some discussion about this general logind stuff a while ago. However, my personal feeling is, all the issues we have with packaging and dependencies now raise from a single source, namely that libsystemd integrates lots of - in my opinion completely - orthogonal functions in a single binary. E.g.: - Managing system init and services - Managing sessions - Managing temporary files - Managing devices ... This is the reason why libelogind has been massively stubbed to become api compatible and this is the reason why it is not possible to simply replace a function like "session management" with another solution. As of my thinking, the only proper solution here would be to kindly, well forcefully insist on systemd upstream to split their library by function and enforce them to link their own binaries properly with these libs. E.g. - libsystemd -> system init and services - libsystem-login -> sessino management - libsystem-udev -> ... Andreas signature.asc Description: PGP signature
Bug#935304: libpam-systemd: Please relax Depends: systemd-sysv (was: Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful) (fwd)
Bummer... Sorry, was #935304 it was aimed for. -- Forwarded message -- Date: Sun, 29 Sep 2019 11:00:10 +0200 (CEST) From: Cristian Ionescu-Idbohrn To: 940...@bugs.debian.org On Sun, 29 Sep 2019, Mark Hindley wrote: > On Sat, Sep 28, 2019 at 11:41:56AM +0200, Thorsten Glaser wrote: > > On Sat, 28 Sep 2019, Cristian Ionescu-Idbohrn wrote: > > > > > 1. install sysvinit-core; that removes systemd-sysv but nothing else > > >systemd related > > > > > Souldn't that work? > > > > It would, if but for libpam-systemd having a (somewhat questionable > > but understandable) dependency on systemd-sysv. This is basically > > what spawned this thread. > > > > So we'll not be going there. > > Thorsten is quite right. > > There is already a separate bug concerning the libpam-systemd > systemd-sysv dependency. See https://bugs.debian.org/935304. That > would be a more appropriate place for you to add any comments you > may have regarding this aspect of the behaviour you have observed. Following Mark's advice, here are my findings: On Sun, 29 Sep 2019, Cristian Ionescu-Idbohrn wrote: > > Right. I see now what happens on my systems. I have an older > version of systemd packages installed: > > , > | Version: 238-5 > ` > > which depends on: > > , > | systemd-shim (>= 10-3~) | systemd-sysv > ` > > as I stopped systemd related package updates: > > , [ /etc/apt/preferences.d/no-systemd ] > | Package: systemd systemd-sysv systemd-sysv:i386 libsystemd0 libpam-systemd > | Pin: release o=Debian > | Pin-Priority: -1 > ` > > at the point when systemd-shim was removed. Does it mean that, in my case, the transition to elogind would be easier? Cheers, -- Cristian
Bug#940034: libpam-systemd: Please relax Depends: systemd-sysv (was: Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful)
On Sun, 29 Sep 2019, Mark Hindley wrote: > On Sat, Sep 28, 2019 at 11:41:56AM +0200, Thorsten Glaser wrote: > > On Sat, 28 Sep 2019, Cristian Ionescu-Idbohrn wrote: > > > > > 1. install sysvinit-core; that removes systemd-sysv but nothing else > > >systemd related > > > > > Souldn't that work? > > > > It would, if but for libpam-systemd having a (somewhat questionable > > but understandable) dependency on systemd-sysv. This is basically > > what spawned this thread. > > > > So we'll not be going there. > > Thorsten is quite right. > > There is already a separate bug concerning the libpam-systemd > systemd-sysv dependency. See https://bugs.debian.org/935304. That > would be a more appropriate place for you to add any comments you > may have regarding this aspect of the behaviour you have observed. Following Mark's advice, here are my findings: On Sun, 29 Sep 2019, Cristian Ionescu-Idbohrn wrote: > > Right. I see now what happens on my systems. I have an older > version of systemd packages installed: > > , > | Version: 238-5 > ` > > which depends on: > > , > | systemd-shim (>= 10-3~) | systemd-sysv > ` > > as I stopped systemd related package updates: > > , [ /etc/apt/preferences.d/no-systemd ] > | Package: systemd systemd-sysv systemd-sysv:i386 libsystemd0 libpam-systemd > | Pin: release o=Debian > | Pin-Priority: -1 > ` > > at the point when systemd-shim was removed. Does it mean that, in my case, the transition to elogind would be easier? Cheers, -- Cristian
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
Cristian, On Sat, Sep 28, 2019 at 11:41:56AM +0200, Thorsten Glaser wrote: > On Sat, 28 Sep 2019, Cristian Ionescu-Idbohrn wrote: > > > 1. install sysvinit-core; that removes systemd-sysv but nothing else > >systemd related > > > Souldn't that work? > > It would, if but for libpam-systemd having a (somewhat questionable > but understandable) dependency on systemd-sysv. This is basically > what spawned this thread. > > So we’ll not be going there. Thorsten is quite right. There is already a separate bug concerning the libpam-systemd systemd-sysv dependency. See https://bugs.debian.org/935304. That would be a more appropriate place for you to add any comments you may have regarding this aspect of the behaviour you have observed. Mark
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
On Sat, 28 Sep 2019, Thorsten Glaser wrote: > On Sat, 28 Sep 2019, Cristian Ionescu-Idbohrn wrote: > > > 1. install sysvinit-core; that removes systemd-sysv but nothing else > >systemd related > > > Souldn't that work? > > It would, if but for libpam-systemd having a (somewhat questionable > but understandable) dependency on systemd-sysv. This is basically > what spawned this thread. > > So we'll not be going there. Right. I see now what happens on my systems. I have an older version of systemd packages installed: , | Version: 238-5 ` which depends on: , | systemd-shim (>= 10-3~) | systemd-sysv ` as I stopped systemd related package updates: , [ /etc/apt/preferences.d/no-systemd ] | Package: systemd systemd-sysv systemd-sysv:i386 libsystemd0 libpam-systemd | Pin: release o=Debian | Pin-Priority: -1 ` at the point when systemd-shim was removed. Cheers, -- Cristian
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
On Sat, Sep 28, 2019 at 02:53:56AM +0200, Thorsten Glaser wrote: > On Fri, 27 Sep 2019, Mark Hindley wrote: > > > Thanks. The aim of preventing accidental removal of systemd is very > > reasonable. However, using this approach the hurdle you create even to a > > user > > who really wants to uninstall is pretty high. Few people will continue > > having > > seen the 'You are about to do something potentially harmful' warning. > > And isn’t that precisely the goal? To prevent most users from > “just hitting Enter” to switch away from the default? That's for when you're knowingly doing something very unusual, that in normal circumstances breaks your whole system. Using a different supported init system is not something that counts here. > I’d assume people wanting to install elogind to proceed > according to documentation telling them that this message > is expected (but to still review what APT wants to do!) > (or just have enough of a clue about Debian to do this > anyway) so this is what I’d suggested, independent even > of the rest of the discussion. You might be comfortable with overriding all safety barriers, but that's not something for regular users. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, ⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month. ⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake, ⠈⠳⣄ etc), let the drink age at least 3-6 months.
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
On Fri, 27 Sep 2019, Mark Hindley wrote: > Thanks. The aim of preventing accidental removal of systemd is very > reasonable. However, using this approach the hurdle you create even to a user > who really wants to uninstall is pretty high. Few people will continue having > seen the 'You are about to do something potentially harmful' warning. And isn’t that precisely the goal? To prevent most users from “just hitting Enter” to switch away from the default? I’d assume people wanting to install elogind to proceed according to documentation telling them that this message is expected (but to still review what APT wants to do!) (or just have enough of a clue about Debian to do this anyway) so this is what I’d suggested, independent even of the rest of the discussion. bye, //mirabilos -- «MyISAM tables -will- get corrupted eventually. This is a fact of life. » “mysql is about as much database as ms access” – “MSSQL at least descends from a database” “it's a rebranded SyBase” “MySQL however was born from a flatfile and went downhill from there” – “at least jetDB doesn’t claim to be a database” (#nosec)‣‣‣ Please let MySQL and MariaDB finally die!
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
On Fri, 27 Sep 2019, Adam Borowski wrote: > > The "init" package has the "Important: yes" control field which as I > That flag is not for "without an explicit user choice". It's for "you're > breaking the packaging system, far more than ignoring dependencies". This is wrong. > It's the biggest hammer dpkg has. This is wrong; the biggest hammer is Conflicts without Replaces, or Pre-Depends. bye, //mirabilos -- Sometimes they [people] care too much: pretty printers [and syntax highligh- ting, d.A.] mechanically produce pretty output that accentuates irrelevant detail in the program, which is as sensible as putting all the prepositions in English text in bold font. -- Rob Pike in "Notes on Programming in C"
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
On Fri, 27 Sep 2019, Julien Cristau wrote: > So one thing I think we should ensure is we don't end up uninstalling > systemd without an explicit user choice. I’ve proposed to suggest to the systemd maintainers to add Important: yes to libsystemd0. (On a different level, adding it to systemd instead would… probably… have the same effect.) I think that should fully solve this concern; I’ve got quite the number of personal packages using Important: yes and have experience with it. bye, //mirabilos -- 15:41⎜ Somebody write a testsuite for helloworld :-)
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
On Sat, 28 Sep 2019, Cristian Ionescu-Idbohrn wrote: > 1. install sysvinit-core; that removes systemd-sysv but nothing else >systemd related > Souldn't that work? It would, if but for libpam-systemd having a (somewhat questionable but understandable) dependency on systemd-sysv. This is basically what spawned this thread. So we’ll not be going there. bye, //mirabilos -- «MyISAM tables -will- get corrupted eventually. This is a fact of life. » “mysql is about as much database as ms access” – “MSSQL at least descends from a database” “it's a rebranded SyBase” “MySQL however was born from a flatfile and went downhill from there” – “at least jetDB doesn’t claim to be a database” (#nosec)‣‣‣ Please let MySQL and MariaDB finally die!
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
On Fri, Sep 27, 2019 at 03:39:43PM +0200, Julien Cristau wrote: > On Fri, Sep 27, 2019 at 09:19:10AM -0400, Sam Hartman wrote: > So one thing I think we should ensure is we don't end up uninstalling > systemd without an explicit user choice. Julien, I appreciate that you are suggesting some additional protection is required against this. However, it appears that the way APT handles the current dependencies already require explicit user choice to be made. Testing on a basic sid desktop install with systemd as pid 1 I get the following behaviour: - apt install libelogind0 Generates the apt "You are about to do something potentially harmful. To continue type in the phrase 'Yes, do as I say!'" warning. - apt install elogind - apt install libpam-elogind For both of these APT fails to find a solution. The only way make it find an solution is to explicitly request installation of sysvinit-core such as 'apt install libpam-elogind sysvinit-core' So I am not sure any changes are required in order to enforce explicit instruction before attempting removal of systemd. Is this sufficient? Mark test@DebianUnstable: ~test@DebianUnstable:~$ dpkg -l systemd* Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-=---=== ii systemd 242-7amd64system and service manager un systemd-container (no description available) un systemd-shim(no description available) ii systemd-sysv 242-7amd64system and service manager - SysV links test@DebianUnstable: ~test@DebianUnstable:~$ sudo apt-get install libelogind0 Reading package lists... Done Building dependency tree... Reading state information... Done The following packages were automatically installed and are no longer required: acl avahi-daemon colord-data gir1.2-matemenu-2.0 gnome-accessibility-themes gnome-themes-extra gnome-themes-extra-data gtk2-engines-pixbuf libargon2-1 libavahi-core7 libayatana-appindicator3-1 libayatana-ido3-0.4-0 libayatana-indicator3-7 libcolorhug2 libcryptsetup12 libdaemon0 libdbusmenu-glib4 libdbusmenu-gtk3-4 libgd3 libgphoto2-6 libgphoto2-l10n libgphoto2-port12 libgusb2 libieee1284-3 libindicator3-7 liblightdm-gobject-1-0 libmate-menu2 libmate-panel-applet-4-1 libmateweather-common libmateweather1 libnss-mdns libplymouth4 librda-common librda0 libsane libsane-common libsnmp-base libsnmp30 lightdm-gtk-greeter mate-menus mate-panel-common mate-polkit-common menu menu-xdg sane-utils update-inetd Use 'sudo apt autoremove' to remove them. The following packages will be REMOVED: colord init libnss-systemd libpam-systemd libsystemd0 lightdm mate-panel mate-polkit plymouth plymouth-label policykit-1 policykit-1-gnome systemd systemd-sysv xiccd The following NEW packages will be installed: libelogind0 WARNING: The following essential packages will be removed. This should NOT be done unless you know exactly what you are doing! init systemd-sysv (due to init) 0 upgraded, 1 newly installed, 15 to remove and 0 not upgraded. Need to get 224 kB of archives. After this operation, 20.1 MB disk space will be freed. You are about to do something potentially harmful. To continue type in the phrase 'Yes, do as I say!' ?] n Abort. test@DebianUnstable: ~test@DebianUnstable:~$ sudo apt-get install elogind Reading package lists... Done Building dependency tree... Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: elogind : Depends: libelogind0 (= 241.3-1+debian1) but it is not going to be installed E: Unable to correct problems, you have held broken packages.
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
Mark, On Fri, 27 Sep 2019, Mark Hindley wrote: > > Thanks. The aim of preventing accidental removal of systemd is very > reasonable. However, using this approach the hurdle you create even > to a user who really wants to uninstall is pretty high. Few people > will continue having seen the 'You are about to do something > potentially harmful' warning. > > I think the effect we are after is rather closer to that of apt-mark > hold systemd or dpkg --set-selections systemd hold. Once held, > uninstalling the package requires a specific request to apt. But I > realise this approach will also prevent upgrades. What about doing this as a three steps operation? 1. install sysvinit-core; that removes systemd-sysv but nothing else systemd related 2. reboot; init should now be sysv init 3. install libelogind0 libpam-elogind elogind Souldn't that work? But some stuff needs to be addressed first. Some 100 packages would be removed on my system: , | The following packages will be REMOVED: | akonadi-server* breeze* drkonqi* ettercap-graphical* ffmpegthumbs* | frameworkintegration* gdebi* isenkram* k3b* kactivitymanagerd* kaffeine* | kamera* kamoso* kcachegrind* kde-cli-tools* kde-config-cddb* | kde-config-screenlocker* kde-runtime* kde-style-breeze* kdeconnect* | kdelibs5-plugins* kdesudo* kinit* kio* kmahjongg* kmenuedit* kommander* | kpat* krusader* kwin-common* kwin-style-breeze* libcolorcorrect5* libk3b7* | libkf5akonadicore5abi2* libkf5akonadiwidgets5abi1* libkf5auth5* | libkf5authcore5* libkf5bookmarks5* libkf5cddb5* libkf5configwidgets5* | libkf5declarative5* libkf5iconthemes5* libkf5kcmutils5* libkf5kdegames7* | libkf5kdelibs4support5* libkf5kdelibs4support5-bin* libkf5kiocore5* | libkf5kiofilewidgets5* libkf5kiogui5* libkf5kiowidgets5* | libkf5kmahjongglib5* libkf5newstuff5* libkf5newstuffcore5* | libkf5notifyconfig5* libkf5parts5* libkf5plasma5* libkf5plasmaquick5* | libkf5purpose-bin* libkf5purpose5* libkf5quickaddons5* libkf5runner5* | libkf5sane5* libkf5style5* libkf5texteditor-bin* libkf5texteditor5* | libkf5textwidgets5* libkf5wallet-bin* libkf5xmlgui5* libkf5xmlrpcclient5* | libkscreenlocker5* libkwin4-effect-builtins1* libokular5core8* | libpam-systemd* libpolkit-qt-1-1* libpolkit-qt5-1-1* libprocessui7* | libtaskmanager6* libvirt-daemon-system* libweather-ion7* milou* okular* | packagekit* plasma-desktop* plasma-framework* plasma-integration* | plasma-workspace* policykit-1* polkit-kde-agent-1* | qml-module-org-kde-draganddrop* qml-module-org-kde-kconfig* | qml-module-org-kde-kcoreaddons* qml-module-org-kde-kquickcontrols* | qml-module-org-kde-kquickcontrolsaddons* qml-module-org-kde-kwindowsystem* | qml-module-org-kde-purpose* qml-module-org-kde-qqc2desktopstyle* rasdaemon* | skanlite* skrooge* systemd* udisks2* ` most of them KDE related, but not only. Bug #925344 (filed on Sat, 23 Mar 2019 13:33:24 +, 6 month ago) needs to be resolved in a speedy manner. But, AFAICS, no progress was made since :( Looking at one of the other packages, udisks2, I see direct and indirect dependencies to systemd: , | Depends: dbus, libblockdev-part2, libblockdev-swap2, | libblockdev-loop2, libblockdev-fs2, libpam-systemd, parted, udev, | ^^ | libacl1 (>= 2.2.23), libatasmart4 (>= 0.13), libblockdev-utils2 (>= | 2.20), libblockdev2 (>= 2.20), libc6 (>= 2.7), libglib2.0-0 (>= 2.50), | libgudev-1.0-0 (>= 165), libmount1 (>= 2.30), libpolkit-agent-1-0 (>= | 0.99), libpolkit-gobject-1-0 (>= 0.101), libsystemd0 (>= 209), | ^^^ | libudisks2-0 (>= 2.8.3) ` Those need to be addressed too. Cheers, -- Cristian
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
Julien, On Fri, Sep 27, 2019 at 03:39:43PM +0200, Julien Cristau wrote: > So one thing I think we should ensure is we don't end up uninstalling > systemd without an explicit user choice. > > The "init" package has the "Important: yes" control field which as I > understand it tells apt to behave like "Essential: yes", except for not > trying to install the package if it is not installed. > > That's not quite enough for our purposes, because apt would still be > allowed to replace systemd-sysv with sysvinit-core, but maybe > systemd-sysv could get that flag as well? > > Julian didn't seem to find the idea crazy when we brought that up on > irc. Thanks. The aim of preventing accidental removal of systemd is very reasonable. However, using this approach the hurdle you create even to a user who really wants to uninstall is pretty high. Few people will continue having seen the 'You are about to do something potentially harmful' warning. I think the effect we are after is rather closer to that of apt-mark hold systemd or dpkg --set-selections systemd hold. Once held, uninstalling the package requires a specific request to apt. But I realise this approach will also prevent upgrades. Mark
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
On Fri, Sep 27, 2019 at 03:39:43PM +0200, Julien Cristau wrote: > So one thing I think we should ensure is we don't end up uninstalling > systemd without an explicit user choice. > > The "init" package has the "Important: yes" control field which as I > understand it tells apt to behave like "Essential: yes", except for not > trying to install the package if it is not installed. > > That's not quite enough for our purposes, because apt would still be > allowed to replace systemd-sysv with sysvinit-core, but maybe > systemd-sysv could get that flag as well? That flag is not for "without an explicit user choice". It's for "you're breaking the packaging system, far more than ignoring dependencies". It's the biggest hammer dpkg has. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, ⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month. ⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake, ⠈⠳⣄ etc), let the drink age at least 3-6 months.
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
On Fri, Sep 27, 2019 at 09:19:10AM -0400, Sam Hartman wrote: > I think it is fair to ask Julien as the bug submitter to engage here > either by coming up with new options that none of us have explored or by > coming up with specific problems. Alternatively it would be reasonable > for him to ask someone else who has more time to dedicate to this issue > to step in. > So one thing I think we should ensure is we don't end up uninstalling systemd without an explicit user choice. The "init" package has the "Important: yes" control field which as I understand it tells apt to behave like "Essential: yes", except for not trying to install the package if it is not installed. That's not quite enough for our purposes, because apt would still be allowed to replace systemd-sysv with sysvinit-core, but maybe systemd-sysv could get that flag as well? Julian didn't seem to find the idea crazy when we brought that up on irc. Cheers, Julien
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
Sam, On Fri, Sep 27, 2019 at 09:19:10AM -0400, Sam Hartman wrote: > > "Mark" == Mark Hindley writes: > > Mark> Sam, Since I cannot get a working and robust dpkg-divert > Mark> solution, I feel the need to revisit the validity of these > Mark> concerns. > > I'd like to push back on the phrasing here. > What i'm hearing is that after spending a couple of weeks exploring ways > to meet these concerns, you'd now like to push back on whether they are > a good idea in the first place. > That seems dismissive both of Julien's concerns and the engineering > effort you and others have spent exploring what the valid options are. > I agree with you that it's time to go back and revisit whether these > concerns are requirements that we can meet. I wasn't intending to be dismissive at all. And I apologise if sloppy or careless use of language on my part gave that impression. [snip] > I think it is fair to ask Julien as the bug submitter to engage here > either by coming up with new options that none of us have explored or by > coming up with specific problems. Alternatively it would be reasonable > for him to ask someone else who has more time to dedicate to this issue > to step in. > > In general, we expect maintainers to respond to RC bugs within two > weeks. > I think that in a situation like this it would be reasonable to expect > Julien to respond within two weeks as well. > However, for your information, DSA is having some significant hardware > challenges and I think he is very involved in that. > I'd recommend being very receptive to a specific request for more time. > > Assuming no response, I think it would be reasonable for you to close > the bug after the timeout arguing that you have considered the issues > he brought up, considered alternative designs, and articulated why this > is the best option. I am happy with that. Thank you for your help, advice and facilitation. Mark
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
Hello Sam, > What i'm hearing is that after spending a couple of weeks exploring ways > to meet these concerns, you'd now like to push back on whether they are > a good idea in the first place. > That seems dismissive both of Julien's concerns and the engineering this is a completely wrong summary of what has been discussed, misleading and shining a bad light on us in a prejudiced way¹. Please do take the time to read (apparently not re-read) the mails sent to this bugreport, in which the various solutions were discussed. Please do also reread wrt. the position of the people involved here. ① Perhaps it’s best if someone else gets involved as mediator? bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg ** Mit der tarent Academy bieten wir auch Trainings und Schulungen in den Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an. Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt. **
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
> "Mark" == Mark Hindley writes: Mark> Sam, Since I cannot get a working and robust dpkg-divert Mark> solution, I feel the need to revisit the validity of these Mark> concerns. I'd like to push back on the phrasing here. What i'm hearing is that after spending a couple of weeks exploring ways to meet these concerns, you'd now like to push back on whether they are a good idea in the first place. That seems dismissive both of Julien's concerns and the engineering effort you and others have spent exploring what the valid options are. I agree with you that it's time to go back and revisit whether these concerns are requirements that we can meet. But that's exactly because you've spent time working to address the concerns. In particular: * You have explored and documented why libelogind0 needs to be a different implementation than libsystemd0: while its API and perhaps DBUS interface is the same, its cgroup interface is very different. * You have explored options for maintaining libsystemd0 and libelogind0 co-installable and described problems with those approaches: namely that there is a significant period on every upgrade where libsystemd0 will be used rathen than libelogind. That period will depend on how many packages are being unpacked before triggers get run. I haven't responded to your text because I disagree with your premis. You seemed to be trying to show that no problem could exist. Since the concern raised explicitly included problems caused by our incomplete understanding of what apt's dependency resolver will do, that's a really hard thing to do, and I'd expect that if you went down that path it would involve formal proofs and some model of apt's behavior. Instead, I think you've done the work to argue that you have the best option anyone has come up with. You've explored the other options Simon and Michael have suggested and explained why they won't work. You've worked with the Apt developers to resolve the concrete problem that Simon had with your approach. In your testing you are not able to produce particularly bad situations. I think it is fair to ask Julien as the bug submitter to engage here either by coming up with new options that none of us have explored or by coming up with specific problems. Alternatively it would be reasonable for him to ask someone else who has more time to dedicate to this issue to step in. In general, we expect maintainers to respond to RC bugs within two weeks. I think that in a situation like this it would be reasonable to expect Julien to respond within two weeks as well. However, for your information, DSA is having some significant hardware challenges and I think he is very involved in that. I'd recommend being very receptive to a specific request for more time. Assuming no response, I think it would be reasonable for you to close the bug after the timeout arguing that you have considered the issues he brought up, considered alternative designs, and articulated why this is the best option. I won't lie: there are various ways politics can happn at that point. I have a couple roles in this: 1) facilitating communications. 2) I'm an experienced Debian Developer. I'm giving you advice on what is reasonable process in handling an RC bug. I don't have any DPL powers in that regard; other DDs may disagree with me. If you want to double check my recommendations with other developers that wouldn't be bad. If other developers pop up here, considering their input would be a good idea. 3) I cannot review specific Release Team decisions. I do have a role in reviewing whether the release team is using a reasonable process and talking to release team members or release managers when I have concerns about that. Ultimately, I can ask the project to review a release team decision if I think the process is unreasonable. (I have the technical power to ask the project to review a decision in other circumstances, but I would be much more reluctant to use that power in a situation where I thought the process was reasonable than in a situation where I thought it was not.) --Sam
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
On Thu, Sep 26, 2019 at 12:52:27PM +0200, Thorsten Glaser wrote: > On Thu, 26 Sep 2019, Mark Hindley wrote: > > It is possible to get APT to attempt a solution by specifically requesting > > 'apt > > install libelogind0 sysvinit-core'. This removes systemd-sysv and then > > fails > > Does it also request a “Yes, do as I say!” then? > > If not (or perhaps anyway) libsystemd0 should get Important: yes, as > I wrote earlier, which will force that. A very bad idea, I'd say. Switching between implementations of the same thing shouldn't require defeating the biggest "stop, you're doing something stupid" block dpkg has. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, ⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month. ⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake, ⠈⠳⣄ etc), let the drink age at least 3-6 months.
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
On Thu, Sep 26, 2019 at 12:52:27PM +0200, Thorsten Glaser wrote: > On Thu, 26 Sep 2019, Mark Hindley wrote: > > > It is possible to get APT to attempt a solution by specifically requesting > > 'apt > > install libelogind0 sysvinit-core'. This removes systemd-sysv and then > > fails > > Does it also request a “Yes, do as I say!” then? No it doesn't. > If not (or perhaps anyway) libsystemd0 should get Important: yes, as > I wrote earlier, which will force that. Yes it could. Thanks Mark
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
On Thu, 26 Sep 2019, Mark Hindley wrote: > It is possible to get APT to attempt a solution by specifically requesting > 'apt > install libelogind0 sysvinit-core'. This removes systemd-sysv and then fails Does it also request a “Yes, do as I say!” then? If not (or perhaps anyway) libsystemd0 should get Important: yes, as I wrote earlier, which will force that. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
Sam, Since I cannot get a working and robust dpkg-divert solution, I feel the need to revisit the validity of these concerns. On Mon, Sep 23, 2019 at 03:03:57PM -0400, Sam Hartman wrote: > > "Mark" == Mark Hindley writes: > >> If we are going to use c/r/p libsystemd0, is there some way we > >> can limit the potential damage to people who have positively > >> indicated that they want to run a non-default init system? One > >> of the concerns is what happens if apt decides somehow that it > >> wants to install libelogind0 when you don't expect it. > > Mark> I have to admit I don't understand this fear. libsystemd0 is > Mark> just a way of talking to a running systemd process. If systemd > Mark> is not running and PID 1 libsystemd0 APIs generally return non > Mark> fatal errors. So by running a non-default init, libsystemd0 is > Mark> only there to satisfy dynamically loaded symbols at > Mark> runtime. Otherwise it is basically non functional. libelogind0 > Mark> is the same if elogind isn't running. > > Foo-package depends on the latest libsystemd0. I'm running unstable or > testing. The latest libsystemd0 isn't building on my arch yet. But > elogind is simpler and has build fine on my arch. I install foo-package > and suddenly end up with libelogind0 instead of libsystemd0 > > This is probably a problem. > Libsystemd0 and libelogind0 probably behave differently and you probably > do care which one you have. Yes, it would be a problem if that was what happened, but if this system had systemd installed, the current dependencies do not allow it. If systemd wasn't installed it might happen. However, I don't think that would cause any change in function. There appears to be some mystique as to what libsystemd0 and libelogind0 do. Their only function is to provide library API access to a running systemd or elogind process. In the absence of that, they do nothing beyond satisfying the runtime linker. > The specific problems depend on what init system I have, on whether I > have elogind running or systemd-logind, etc. > But it's probably not a good situation. Yes, so problems and loss of functionality are caused only if you end up with the combination systemd/libelogind0 or elogind/libsystemd0. Current dependencies make the first of these impossible and second one is what we are trying to provide a solution to. To be sure, I have just tried to install libelogind0 on a sid VM booted with systemd. APT will not let you do it requiring you to type the 'Yes, do as I say!' phrase after its serious warning which is surely enough to dissuade most people from proceeding. The dependency stack is init (Priority: important) PreDepends systemd-sysv systemd-sysv (Priority: important) PreDepends systemd libelogind0 conflicts systemd Given that, I can see no way libelogind0 could accidentally be installed on a system with systemd. It is possible to get APT to attempt a solution by specifically requesting 'apt install libelogind0 sysvinit-core'. This removes systemd-sysv and then fails gracefully when the systemd prerm fails. 'apt -f install' successfully cleans up by configuring sysvinit-core. This would only be specified by a user wanting to switch to an non-default init and is not going to happen by accident. Importantly in this scenario, libelogind0 is still not installed and the system including systemd as init still functions. If you realise you have made a mistake you can even return to systemd-sysv just by reinstalling it. I hope you don't feel I am going over old ground here, but I fail to see a case that is not covered. What am I missing? Mark
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
On Thu, Sep 26, 2019 at 12:11:47AM +0200, Thorsten Glaser wrote: > On Wed, 25 Sep 2019, Mark Hindley wrote: > > > Thanks. Triggers may be an answer to the libsystemd soversion issue. > > Mind that anything that runs between unpacking the new libsystemd0 > and running the trigger will use libsystemd0 instead of libelogind0. Ah, of course! Sam, I don't see a way of implementing a robust dpkg-divert solution. Sorry. Mark
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
On Wed, 25 Sep 2019, Mark Hindley wrote: > Thanks. Triggers may be an answer to the libsystemd soversion issue. Mind that anything that runs between unpacking the new libsystemd0 and running the trigger will use libsystemd0 instead of libelogind0. > > I don’t like this approach. > > In this usage case, I believe I have avoided this being a problem. I really don’t like it and I believe contrary still, see above. > The flow to > switch to libelogind.so goes > > 1) symlink libelogind.so.0 to a temporary file. > 2) rename temporary file to libsystemd.so.0 (I believe this is atomic). It is, if the temporary file is housed under the same directory. > 3) dpkg-divert libsystemd.so.0.26.0 out of the way so ldconfig can't find it. > 4) Whenever ldconfig runs the manual symlink libsystemd.so.0 -> > libelogind.so.0 > is preserved. The packages ship the symlinks as well though, so each and any update of libsystemd0 will wreck them. Oh… and, habe you considered Multi-Arch? bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
On Wed, Sep 25, 2019 at 10:09:15PM +0200, Thorsten Glaser wrote: > On Wed, 25 Sep 2019, Mark Hindley wrote: > > > libelogind0 can be coninstalled with libsystemd0. However, it is fragile > > because > > the file that needs to be diverted out of the way is libsystemd.so.0.26.0 > > (the > > actual library file, not a symlink) otherwise ldconfig will still find it > > and > > create symlinks. However, AFAICS dpkg-divert doesn't accept wildcards and > > so if > > the minor soversion is bumped and a new version of libsystemd0 is > > installed, the > > new file is installed without a divert and ldconfig redirects the symlink. > > Yes, this is not a good idea. > > You could do with a trigger on /usr/lib/ and a wildcard-expanding > shell loop in postinst, which is also a tad fragile. Thanks. Triggers may be an answer to the libsystemd soversion issue. > dpkg-divert also has a small period in which neither is available. > I don’t like this approach. In this usage case, I believe I have avoided this being a problem. The flow to switch to libelogind.so goes 1) symlink libelogind.so.0 to a temporary file. 2) rename temporary file to libsystemd.so.0 (I believe this is atomic). 3) dpkg-divert libsystemd.so.0.26.0 out of the way so ldconfig can't find it. 4) Whenever ldconfig runs the manual symlink libsystemd.so.0 -> libelogind.so.0 is preserved. I believe using a temporary file and then renaming means there is no point at which there is a valid libsystemd.so.0 symlink. But I could be wrong. This isn't the same as the 'standard' dpkg-divert when a file is moved out of the way so another can be installed in it's place Is this still flawed? Thanks Mark
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
On Wed, 25 Sep 2019, Sam Hartman wrote: > Thorsten> dpkg-divert also has a small period in which neither is > Thorsten> available. I don’t like this approach. > > Is that only when adding a diversion or when upgrading a diverted file > each time? When adding a diversion. dpkg-divert is smart enough that, when the prerm does NOT remove the diversion (e.g. if you have it in postrm instead), when the postinst adds it to make that to a nop. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
> "Thorsten" == Thorsten Glaser writes: Thorsten> On Wed, 25 Sep 2019, Mark Hindley wrote: >> libelogind0 can be coninstalled with libsystemd0. However, it is >> fragile because the file that needs to be diverted out of the way >> is libsystemd.so.0.26.0 (the actual library file, not a symlink) >> otherwise ldconfig will still find it and create >> symlinks. However, AFAICS dpkg-divert doesn't accept wildcards >> and so if the minor soversion is bumped and a new version of >> libsystemd0 is installed, the new file is installed without a >> divert and ldconfig redirects the symlink. Thorsten> dpkg-divert also has a small period in which neither is Thorsten> available. I don’t like this approach. Is that only when adding a diversion or when upgrading a diverted file each time?
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
On Wed, 25 Sep 2019, Mark Hindley wrote: > libelogind0 can be coninstalled with libsystemd0. However, it is fragile > because > the file that needs to be diverted out of the way is libsystemd.so.0.26.0 (the > actual library file, not a symlink) otherwise ldconfig will still find it and > create symlinks. However, AFAICS dpkg-divert doesn't accept wildcards and so > if > the minor soversion is bumped and a new version of libsystemd0 is installed, > the > new file is installed without a divert and ldconfig redirects the symlink. Yes, this is not a good idea. You could do with a trigger on /usr/lib/ and a wildcard-expanding shell loop in postinst, which is also a tad fragile. dpkg-divert also has a small period in which neither is available. I don’t like this approach. If it’s just for not switching by accident, the Important: yes binary control field, which I mentioned in my other mail, is more apropos. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
On Mon, Sep 23, 2019 at 04:16:05PM -0400, Sam Hartman wrote: > Mark> Anyway, I am happy to try to work up a dpkg-divert solution if > Mark> that is likely to be more acceptable. > > I don't know if it will be. > I'm trying to be a facilitator here and make sure all sides understand > each other. > > So, the advantage of the dpkg-divert approach seems to me to be that if > you never turn it on, it can't hurt you. > So, for example, if you do more than install a package to trigger it, it > could be very safe for the systemd user. > > Even if you trigger from the elogind postinst, that's probably OK so > long as very little hard depends on elogind. > > The disadvantages are: > > 1) Making sure you never get into a situation where you try to boot > systemd with libelogind0. Assuming you can dpkg-divert a symlink, you > can presumably manage the /sbin/init link, but you cannot stop someone > from init=/bin/systemd with libelogind0 as libsystemd0. Although > systemd doesn't actually link to libsystemd0, so perhaps that's not > quite as bad as I thought, although I'm sure it isn't good.. (You may > not need to stop this: it's a disadvantage, and sometimes the chosen > solution has disadvantages). > > 2) There was FUD about dpkg-divert being inappropriate for critical > system functions. I don't know whether this is still true or how big of > a deal it is. But for example if things are in an inconsistent state on > upgrade between unpack phase and configure phase, that might be a > disadvantage. Basically, I think it's probably fine if the initial > diversion has some fragility (where if your system crashes at that one > point, recovery is hard). I think it's less amazing if every time you > upgrade systemd, elogind or similar, there is fragility. I have got a PoC dpkg-divert solution working. The divert created in elogind.postinst and removed in elogind.prerm. The libsystemd.so compatibility symlink is also handled there. It works as far as it goes and it means that libelogind0 can be coninstalled with libsystemd0. However, it is fragile because the file that needs to be diverted out of the way is libsystemd.so.0.26.0 (the actual library file, not a symlink) otherwise ldconfig will still find it and create symlinks. However, AFAICS dpkg-divert doesn't accept wildcards and so if the minor soversion is bumped and a new version of libsystemd0 is installed, the new file is installed without a divert and ldconfig redirects the symlink. I can't work out a way around this at the moment, but any suggestions are welcome. Thanks Mark
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
On Mon, 23 Sep 2019, Sam Hartman wrote: > Mark> #935910 is now fixed in apt 1.8.4 in unstable and with that > Mark> installed I can no longer reproduce #934491. The APT > Mark> maintainers have said that adding a Breaks for the fixed > Mark> version of apt is not useful. > > Normally in a situation like this we would wait until the next stable > release for depending on the change in apt. The change can be backported to buster-updates, though. AFAIR we even require (in the install/upgrade/release notes) that people upgrade the old distro version to the fullest before attempting an upgrade to the new one. > So, I think I understand Julian's issues better after trying to write my > bits from the DPL mail. > You haven't really tried to address them at all. AIUI the problem is that the elogind people tried to do X after trying to get advice, which didn’t fly, then someone told the elogind people to do Y, and they did it, and now Julien says “don’t do Y”. I understand this is all tricky, but the elogind people are caught between several places of mutually mismatching expectations. > Foo-package depends on the latest libsystemd0. I'm running unstable or > testing. The latest libsystemd0 isn't building on my arch yet. But > elogind is simpler and has build fine on my arch. I install foo-package > and suddenly end up with libelogind0 instead of libsystemd0 If you add XB-Important: yes to the libsystemd0 binary package stanza in debian/control in src:systemd, APT will not do that. It will then furthermore require “Yes, do as I say!” instead of a simple y or Enter when switching away from libsystemd0. (That being said, I’d expect the elogind package to not be the first to have a bump of the versioned Provides.) This is probably a good idea independent of what else will be done? bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg ** Mit der tarent Academy bieten wir auch Trainings und Schulungen in den Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an. Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt. **
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
On Tue, 2019-09-24 at 10:05 +0100, Mark Hindley wrote: > Ian, > > Thanks for this. > > On Tue, Sep 24, 2019 at 07:28:29AM +0800, Ian Campbell wrote: > > On Fri, 2019-09-20 at 10:16 +0100, Mark Hindley wrote: > > Would it be any help at all of the "dbus client-ish" bits and the > > "direct API-ish" bits of the two libraries were split up into two > > separate libraries? i.e. would that allow the c/r/p replacement of > one > > of the two libraries (AIUI the API one is the more problematic) to > be > > pushed further up the dependency stack? > > I think that is what we already have (if I have understood you correctly). The > dbus components are in systemd/elogind and the sd-*(3) APIs are in > libsystemd0/libelogind0. Or have I misunderstood? Probably I have, I thought the dbus client side stuff was in libsystemd0/libelogind0 too. > > Has anyone investigated late dynamic binding using a stub library which > > merely determines which init is running and then dlopens the > > appropriate libsystemd0 of libelogind0 library and forwards the calls > > to it? > > > I don't know if the dynamic linker could be coerced into doing the > > selection automagically, in a way similar to how the hwcap stuff can be > > used to pickup versions of libraries optimised for different classes of > > processor. hwcap is provided by the kernel so I think can't be used > > directly, but maybe there is a parallel mechanism somewhere? > > I think Adam Borowski suggested somthing similar a while ago as an option, > but I > am not aware of anything more than an idea. Might be worth a PoC? > I also experimented with LD_PRELOAD a while ago. But it felt very hackish. Yeah. that's probably not the way to go. Ian.
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
Ian, Thanks for this. On Tue, Sep 24, 2019 at 07:28:29AM +0800, Ian Campbell wrote: > On Fri, 2019-09-20 at 10:16 +0100, Mark Hindley wrote: > Would it be any help at all of the "dbus client-ish" bits and the > "direct API-ish" bits of the two libraries were split up into two > separate libraries? i.e. would that allow the c/r/p replacement of one > of the two libraries (AIUI the API one is the more problematic) to be > pushed further up the dependency stack? I think that is what we already have (if I have understood you correctly). The dbus components are in systemd/elogind and the sd-*(3) APIs are in libsystemd0/libelogind0. Or have I misunderstood? > Has anyone investigated late dynamic binding using a stub library which > merely determines which init is running and then dlopens the > appropriate libsystemd0 of libelogind0 library and forwards the calls > to it? > I don't know if the dynamic linker could be coerced into doing the > selection automagically, in a way similar to how the hwcap stuff can be > used to pickup versions of libraries optimised for different classes of > processor. hwcap is provided by the kernel so I think can't be used > directly, but maybe there is a parallel mechanism somewhere? I think Adam Borowski suggested somthing similar a while ago as an option, but I am not aware of anything more than an idea. I also experimented with LD_PRELOAD a while ago. But it felt very hackish. Mark
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
On Tue, 24 Sep 2019 07:28:29 +0800 Ian Campbell wrote: > Has anyone investigated late dynamic binding using a stub library > which merely determines which init is running and then dlopens the > appropriate libsystemd0 of libelogind0 library and forwards the calls > to it? it could be in the form of libglvnd, a generic dispatcher to have co-installed multiple vendor implementations of libgl, with runtime selection https://github.com/NVIDIA/libglvnd a stripped down version of that architecture could be used to simply detect what init system is actually running and then dispatch to the correct library (libsystemd or libelogind) ciao!
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
On Fri, 2019-09-20 at 10:16 +0100, Mark Hindley wrote: > On Fri, Sep 20, 2019 at 09:06:57AM +0200, Laurent Bigonville wrote: > > Hello, > > > > When I looked I elogind a while back I was able to build a package without > > having a public libelogind0, I basically had that in my debian/rules file: > > > > # We only build the libelogind0 and libelogind-dev if we are building for > > # Devuan or its derivatives > > ifneq ($(shell dpkg-vendor --derives-from Devuan && yes), yes) > > export DH_OPTIONS=--no-package=libelogind0 --no-package=libelogind-dev > > endif > > > > libelogind library is only needed for applications that want to interact > > with the daemon, in the ITP (#905388) bug I also noted that. > > > > If I'm not mistaken, libsystemd (and libelogind) are using D-Bus to > > communicate with the daemon part, was it checked that the API used is > > compatible? Is there documentation of the differences, if any? > > Yes, the APIs are the same (deliberately so). > > > Bottom line, is libelogind even needed in the archive to achieve your goal > > of having an implementation of the login1 D-Bus API not requiring systemd as > > PID1? > > Thanks. > > I think you are correct that the login1 DBus API doesn't require libsystemd0 > or > libelogind0. However some packages, notably policykit use the sd-login(3) API > which is part of libsystemd0 or libelogind0. Whilst the APIs, and symbol ABIs > are the same between the two libraries (with the caveats noted in the > libelogind0 package description) the implementations differ. I have been tolkd > int he past by elogind upstream that it is not possible for elogind to use > libsystemd0. For example libsystemd0 requires the concept of slices which > elogind doesn't have. Would it be any help at all of the "dbus client-ish" bits and the "direct API-ish" bits of the two libraries were split up into two separate libraries? i.e. would that allow the c/r/p replacement of one of the two libraries (AIUI the API one is the more problematic) to be pushed further up the dependency stack? (my impression is no, but I thought I'd ask) > The only way I have got all of these components to work together on an elogind > systemd is to ensure everything uses libelogind0. Has anyone investigated late dynamic binding using a stub library which merely determines which init is running and then dlopens the appropriate libsystemd0 of libelogind0 library and forwards the calls to it? I don't know if the dynamic linker could be coerced into doing the selection automagically, in a way similar to how the hwcap stuff can be used to pickup versions of libraries optimised for different classes of processor. hwcap is provided by the kernel so I think can't be used directly, but maybe there is a parallel mechanism somewhere? Ian.
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
> "Mark" == Mark Hindley writes: Mark> On Mon, Sep 23, 2019 at 03:03:57PM -0400, Sam Hartman wrote: >> Foo-package depends on the latest libsystemd0. I'm running >> unstable or testing. The latest libsystemd0 isn't building on my >> arch yet. But elogind is simpler and has build fine on my arch. >> I install foo-package and suddenly end up with libelogind0 >> instead of libsystemd0 >> >> This is probably a problem. Libsystemd0 and libelogind0 probably >> behave differently and you probably do care which one you have. >> The specific problems depend on what init system I have, on >> whether I have elogind running or systemd-logind, etc. But it's >> probably not a good situation. Mark> I believe we have guarded against exactly this already because Mark> libelogind0 conflicts with systemd, so you couldn't change Mark> from libsystemd0 to libelogind0 on a systemd install without Mark> removing the running systemd (which won't happen). Well, we've guaranteed that you won't succeed. With the apt fix, we've guaranteed that the dependency order will be respected for removal. But I think it's still possible to get an incredible mess of your systemd. There's no guarantee that systemd removal will happen early in the process. Mark> Anyway, I am happy to try to work up a dpkg-divert solution if Mark> that is likely to be more acceptable. I don't know if it will be. I'm trying to be a facilitator here and make sure all sides understand each other. So, the advantage of the dpkg-divert approach seems to me to be that if you never turn it on, it can't hurt you. So, for example, if you do more than install a package to trigger it, it could be very safe for the systemd user. Even if you trigger from the elogind postinst, that's probably OK so long as very little hard depends on elogind. The disadvantages are: 1) Making sure you never get into a situation where you try to boot systemd with libelogind0. Assuming you can dpkg-divert a symlink, you can presumably manage the /sbin/init link, but you cannot stop someone from init=/bin/systemd with libelogind0 as libsystemd0. Although systemd doesn't actually link to libsystemd0, so perhaps that's not quite as bad as I thought, although I'm sure it isn't good.. (You may not need to stop this: it's a disadvantage, and sometimes the chosen solution has disadvantages). 2) There was FUD about dpkg-divert being inappropriate for critical system functions. I don't know whether this is still true or how big of a deal it is. But for example if things are in an inconsistent state on upgrade between unpack phase and configure phase, that might be a disadvantage. Basically, I think it's probably fine if the initial diversion has some fragility (where if your system crashes at that one point, recovery is hard). I think it's less amazing if every time you upgrade systemd, elogind or similar, there is fragility. Really at this point we need someone who is not you or I to speak up.
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
On Mon, Sep 23, 2019 at 03:34:50PM -0400, Sam Hartman wrote: > Hi. > I've looked a bit at the systemd code as compared to the elogind code. > > One of the major reasons that libsystemd0 cannot be used as a > replacement for libelogind0 is that elogind does not have compatible > cgroup naming. > The systemd (and elogind) libraries do some operations over dbus. > But other operations are done directly. For example to look and see > what session a pid is in, the library will look at the cgroups of the > pid. > Similarly to see whether a particular pid belongs to a uid, it looks at > the cgroup naming. > > If you take a look at src/basic/cgroup-util.c in the elogind sources and > take a look at what is #if 0'd you can see the naming differences. Yes. systemd uses user units and scopes. elogind can not support either and uses internal hash containers. So if a system is running elogind and polkit asks libsystemd0 for a session id to a pid, it will search for a session-.scope and find nothing. See the two implementations of cg_path_get_session(): https://github.com/elogind/elogind/blob/d4a3f29/src/basic/cgroup-util.c#L1713 Mark
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
On Mon, Sep 23, 2019 at 03:03:57PM -0400, Sam Hartman wrote: > Foo-package depends on the latest libsystemd0. I'm running unstable or > testing. The latest libsystemd0 isn't building on my arch yet. But > elogind is simpler and has build fine on my arch. I install foo-package > and suddenly end up with libelogind0 instead of libsystemd0 > > This is probably a problem. > Libsystemd0 and libelogind0 probably behave differently and you probably > do care which one you have. > The specific problems depend on what init system I have, on whether I > have elogind running or systemd-logind, etc. > But it's probably not a good situation. I believe we have guarded against exactly this already because libelogind0 conflicts with systemd, so you couldn't change from libsystemd0 to libelogind0 on a systemd install without removing the running systemd (which won't happen). > The concern is there might be other cases where the dependency resolver > gives you an answer that is inappropriate for your environment. We're > not sure we have confidence we can enumerate and think about all these > situations. I agree we can't envisage all cases, but that is what testing is for. Anyway, I am happy to try to work up a dpkg-divert solution if that is likely to be more acceptable. Thanks. Mark
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
Hi. I've looked a bit at the systemd code as compared to the elogind code. One of the major reasons that libsystemd0 cannot be used as a replacement for libelogind0 is that elogind does not have compatible cgroup naming. The systemd (and elogind) libraries do some operations over dbus. But other operations are done directly. For example to look and see what session a pid is in, the library will look at the cgroups of the pid. Similarly to see whether a particular pid belongs to a uid, it looks at the cgroup naming. If you take a look at src/basic/cgroup-util.c in the elogind sources and take a look at what is #if 0'd you can see the naming differences. I don't know what would happen if you built a elogind that used systemd naming. I don't know what the next hurtle would be. --Sam
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
> "Mark" == Mark Hindley writes: >> If we are going to use c/r/p libsystemd0, is there some way we >> can limit the potential damage to people who have positively >> indicated that they want to run a non-default init system? One >> of the concerns is what happens if apt decides somehow that it >> wants to install libelogind0 when you don't expect it. Mark> I have to admit I don't understand this fear. libsystemd0 is Mark> just a way of talking to a running systemd process. If systemd Mark> is not running and PID 1 libsystemd0 APIs generally return non Mark> fatal errors. So by running a non-default init, libsystemd0 is Mark> only there to satisfy dynamically loaded symbols at Mark> runtime. Otherwise it is basically non functional. libelogind0 Mark> is the same if elogind isn't running. Foo-package depends on the latest libsystemd0. I'm running unstable or testing. The latest libsystemd0 isn't building on my arch yet. But elogind is simpler and has build fine on my arch. I install foo-package and suddenly end up with libelogind0 instead of libsystemd0 This is probably a problem. Libsystemd0 and libelogind0 probably behave differently and you probably do care which one you have. The specific problems depend on what init system I have, on whether I have elogind running or systemd-logind, etc. But it's probably not a good situation. The concern is there might be other cases where the dependency resolver gives you an answer that is inappropriate for your environment. We're not sure we have confidence we can enumerate and think about all these situations. This is less likely with things like mail-transport-agent because the dependencies are closer to their usage, or because the size of the interacting parts of the dependency graph are smaller.
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
Sam, Many thanks for this. On Mon, Sep 23, 2019 at 11:58:18AM -0400, Sam Hartman wrote: Mark> I have tried the approach suggested by Laurent of using Mark> elogind with libsystemd0 and I could not get the sd-*(3) APIs Mark> to function correctly. > What trouble did you run into? That sd-login(3) APIs failed to match pids to the current session and so policykit authorisation failed. > So, I think I understand Julian's issues better after trying to write my > bits from the DPL mail. You have explained Julian's position and concerns far more clearly than has ever been the case directly to me. > You haven't really tried to address them at all. Hmmm. I think I have in line with the clarity with which they have been expressed. But let's move on. > His issue is that we have a long history of trouble with apt and c/r/p > being used this deep in the dependency chain. > So, he's arguing that you have a high bar (possibly infinitely high) for > using that approach. > > Ultimately he wants you to produce a solution where multiple init > systems can be coinstalled and where you don't need a conflicts. OK. But elogind is not an init. sysvinit-core and systemd are coinstallable, but not sysvinit-core and systemd-sysv. Do you mean he wants elogind and systemd to be coninstallable? > I think you've explored some of that design space and have a feel for > why some of that is unattractive. > As an example, if you have systemd installed, it might be running. The > combination of systemd running and libelogind0 being the systemd library > is unfortunate. Trying to boot systemd in that configuration (using > libelogind0) would presumably be quite fatal. Yes and this is currently prevented because both elogind and libelogind0 conflict with systemd. > So, the next question is why libelogind0 needs to exist. That is why > can't you just use libsystemd0 with elogind? > What I've heard so far is "It doesn't work." This was asked of elogind upstream this question almost a year ago: https://github.com/elogind/elogind/issues/97 In particular Yamakazure replied "What I can guarantee is, that if you link something against libsystemd, and then use elogind, that "something" will not work, as the inner workings of libsystemd are quite different. So keeping libsystemd around is no option. But if libsystemd is gone and simply replaced by libelogind, it might work." And we have since demonstrated that once the libelogind0 exposes the same ABI as libsystemd0 so it can be used as a direct replacement, it does work. A couple of days ago I built elogind without libelogind0 and installed it on a system with sysvinit-core and libsystemd0. Applications using the sd-login(3) API, most notably policykit-1 failed to associate pids and sessions and so all policykit-based authentication failed. > Why doesn't it work? How hard would it be to make it work? I am not completely sure. But I think it is because elogind and systemd-login store information in /sys/fs/cgroup/ differently because elogind does not have or need many of the features of systemd. Currently you need a matched pair, either systemd/libsystemd0 or elogind/libelogind0 for successful operation. elogind is never going to have all the features of systemd. That would be pointless. If you want or require all of those features, just use systemd. > Would that be better for Debian than using c/r/p? > And the answer to some of these might be "we don't know and we don't > have anyone who can find out." > That is a fine answer to give, although it might also be fine for the > release team to say that they want that analysis before committing to > something dangerous like c/r/p libsystemd0. > > But even if we understand why libelogind0 is needed, then why do we need > c/r/p libsystemd0? > Could we do something with dpkg-divert? Would that be better? It might possibly work. I will try it out. But, playing devil's advocate, I don't really see the difference: you will still be replacing libsystemd.so with libelogind.so. The only difference is where it happens -- in the package or via dpkg-divert. > If we are going to use c/r/p libsystemd0, is there some way we can limit > the potential damage to people who have positively indicated that they > want to run a non-default init system? > One of the concerns is what happens if apt decides somehow that it wants > to install libelogind0 when you don't expect it. I have to admit I don't understand this fear. libsystemd0 is just a way of talking to a running systemd process. If systemd is not running and PID 1 libsystemd0 APIs generally return non fatal errors. So by running a non-default init, libsystemd0 is only there to satisfy dynamically loaded symbols at runtime. Otherwise it is basically non functional. libelogind0 is the same if elogind isn't running. So the scenarios I can see are 1) systemd PID 1 with libsystemd0 2) alternative init with libsystemd0 3) alternative init with libelogind0 4) no init
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
On Mon, Sep 23, 2019 at 11:58:18AM -0400, Sam Hartman wrote: > Mark> #935910 is now fixed in apt 1.8.4 in unstable and with that > Mark> installed I can no longer reproduce #934491. The APT > Mark> maintainers have said that adding a Breaks for the fixed > Mark> version of apt is not useful. > > Normally in a situation like this we would wait until the next stable > release for depending on the change in apt. > It's a bit complicated because it is a bug, but Julian's idea that we > need to wait until bullseye+1 to depend on this apt fix is not an > unreasonable approach. So this avenue is right out. Fixing the GUI uninstallability regression and backporting it to Buster is urgent, waiting whole two years is not an option. We did have elogind coinstallable with libsystemd0 (before version 241.1-1+debian1) and at least for all _my_ use cases it worked well. As I'm aware, the main problem is policykit, right? There were initial ideas, not liked by its maintainer, but we can analyze further. Having some idea about other possible failures would be nice. > Mark> I have tried the approach suggested by Laurent of using > Mark> elogind with libsystemd0 and I could not get the sd-*(3) APIs > Mark> to function correctly. > What trouble did you run into? If whatever trouble (not yet named) can't be fixed on the other side of daemon, we can perhaps patch libsystemd0 itself? > As an example, if you have systemd installed, it might be running. The > combination of systemd running and libelogind0 being the systemd library > is unfortunate. Trying to boot systemd in that configuration (using > libelogind0) would presumably be quite fatal. Right, both must be coinstallable; with systemd-logind gracefully refusing to start when booted with some other init, and elogind likewise not starting when systemd-the-init is pid 1. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, ⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month. ⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake, ⠈⠳⣄ etc), let the drink age at least 3-6 months.
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
> "Mark" == Mark Hindley writes: Mark> Julian, Mark> On Wed, Sep 11, 2019 at 02:28:55PM +0100, Mark Hindley wrote: >> > I don't think it's reasonable to ship this package with C/R/P > >> libsystemd0. >> >> I understand that you don't like it. However, for libelogind0 to >> export the same symbols as libsystemd0 so that it could C/R/P >> libsystemd0 was the agreed solution to bug #923244. >> >> Do you have another suggestion as to how we could have resolved >> that? Other solutions were discounted at the time. >> >> > I think it opens you (and, more importantly, users) up to >> issues like > #934491. Even if #935910 were to be fixed in the >> package manager > in > bullseye, it would still mean libelogind0 >> couldn't ship with > the C/R/P > until bullseye+1. >> >> I think it seems likely from discussions on #debian-dpkg that >> #935910 will be fixed in APT and #934491 can be addressed by >> adding Breaks: << fixed APT. Mark> #935910 is now fixed in apt 1.8.4 in unstable and with that Mark> installed I can no longer reproduce #934491. The APT Mark> maintainers have said that adding a Breaks for the fixed Mark> version of apt is not useful. Normally in a situation like this we would wait until the next stable release for depending on the change in apt. It's a bit complicated because it is a bug, but Julian's idea that we need to wait until bullseye+1 to depend on this apt fix is not an unreasonable approach. Mark> I have tried the approach suggested by Laurent of using Mark> elogind with libsystemd0 and I could not get the sd-*(3) APIs Mark> to function correctly. What trouble did you run into? Mark> Are there any outstanding issues that you would like me to Mark> address to resolve this bug? So, I think I understand Julian's issues better after trying to write my bits from the DPL mail. You haven't really tried to address them at all. His issue is that we have a long history of trouble with apt and c/r/p being used this deep in the dependency chain. So, he's arguing that you have a high bar (possibly infinitely high) for using that approach. Ultimately he wants you to produce a solution where multiple init systems can be coinstalled and where you don't need a conflicts. I think you've explored some of that design space and have a feel for why some of that is unattractive. As an example, if you have systemd installed, it might be running. The combination of systemd running and libelogind0 being the systemd library is unfortunate. Trying to boot systemd in that configuration (using libelogind0) would presumably be quite fatal. So, the next question is why libelogind0 needs to exist. That is why can't you just use libsystemd0 with elogind? What I've heard so far is "It doesn't work." Why doesn't it work? How hard would it be to make it work? Would that be better for Debian than using c/r/p? And the answer to some of these might be "we don't know and we don't have anyone who can find out." That is a fine answer to give, although it might also be fine for the release team to say that they want that analysis before committing to something dangerous like c/r/p libsystemd0. But even if we understand why libelogind0 is needed, then why do we need c/r/p libsystemd0? Could we do something with dpkg-divert? Would that be better? If we are going to use c/r/p libsystemd0, is there some way we can limit the potential damage to people who have positively indicated that they want to run a non-default init system? One of the concerns is what happens if apt decides somehow that it wants to install libelogind0 when you don't expect it. It might be better to have some init-chooser app where you had to explicitly decide you wanted to opt into a non-default init before it was possible to get into a situation where libsystemd0 was provided by libelogind0. I don't see how to make that work; I'm just brainstorming. I think it is reasonable for you to expect Julien to be constructively engaged in the discussion, to find someone else who will constructively engage and take ownership of his position, or for the bug to close. At one level Julien is frustrated: you haven't been addressing his core issue of the design choice to use c/r/p libsystemd0 and to not have multiple inits coinstallable. But at another level Julien has stalled your project for multiple months, and if we're going to do that we need to be prepared to engage in trying to actually solve the problem. I think some of the frustration here may stem from you not knowing how to respond to his issue. You don't have a design without c/r/p libsystemd0 that meets your needs. And so you've been focusing on trying to solve the things you could, hoping that would be enough. Where as a great way to engage with an issue like this is to explain why Julien is asking you to do something hard and ask him to work with you to find
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
Julian, On Wed, Sep 11, 2019 at 02:28:55PM +0100, Mark Hindley wrote: > > I don't think it's reasonable to ship this package with C/R/P > > libsystemd0. > > I understand that you don't like it. However, for libelogind0 to export the > same > symbols as libsystemd0 so that it could C/R/P libsystemd0 was the agreed > solution to bug #923244. > > Do you have another suggestion as to how we could have resolved that? Other > solutions were discounted at the time. > > > I think it opens you (and, more importantly, users) up to issues like > > #934491. Even if #935910 were to be fixed in the package manager in > > > > > bullseye, it would still mean libelogind0 couldn't ship with the C/R/P > > until bullseye+1. > > I think it seems likely from discussions on #debian-dpkg that #935910 will be > fixed in APT and #934491 can be addressed by adding Breaks: << fixed APT. #935910 is now fixed in apt 1.8.4 in unstable and with that installed I can no longer reproduce #934491. The APT maintainers have said that adding a Breaks for the fixed version of apt is not useful. I have tried the approach suggested by Laurent of using elogind with libsystemd0 and I could not get the sd-*(3) APIs to function correctly. Are there any outstanding issues that you would like me to address to resolve this bug? Thanks. Mark
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
Laurent, On Fri, Sep 20, 2019 at 09:06:57AM +0200, Laurent Bigonville wrote: > Hello, > > When I looked I elogind a while back I was able to build a package without > having a public libelogind0, I basically had that in my debian/rules file: > > # We only build the libelogind0 and libelogind-dev if we are building for > # Devuan or its derivatives > ifneq ($(shell dpkg-vendor --derives-from Devuan && yes), yes) > export DH_OPTIONS=--no-package=libelogind0 --no-package=libelogind-dev > endif I have just tested this approach. The build and install seems OK. However, applications using the sd-*(3) APIs through libsystemd.so (most notably src:polickit-1) fail to match pids to sessions despite the session being registered correctly with elogind. Normal functionality is restored by installing libelogind0 and restarting polkitd. Sorry. Mark
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
Laurent, On Fri, Sep 20, 2019 at 01:29:43PM +0200, Laurent Bigonville wrote: > Can't this be stubbed or mocked on the elogind side? I presume you mean slices here? (I am not sure that slices are the only difference in implementation, but let's ignore that for now). To be honest, I am not sure. Possibly, but I have my doubts that upstream would be interested in doing it: elogind has no use for them. Although they have already been very accommodating by stubbing out all the APIs in libelogind0 to be binary compatible with libsystemd0. As I see it, if you want slices and all of the other features that systemd provides, use systemd. If you want a slimmed down implementation of DBus login1 and sd-login(3) to use when systemd is not PID1, then elogind might be useful. Mark
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
On 20/09/19 11:16, Mark Hindley wrote: On Fri, Sep 20, 2019 at 09:06:57AM +0200, Laurent Bigonville wrote: [...] Bottom line, is libelogind even needed in the archive to achieve your goal of having an implementation of the login1 D-Bus API not requiring systemd as PID1? Thanks. I think you are correct that the login1 DBus API doesn't require libsystemd0 or libelogind0. However some packages, notably policykit use the sd-login(3) API which is part of libsystemd0 or libelogind0. Whilst the APIs, and symbol ABIs are the same between the two libraries (with the caveats noted in the libelogind0 package description) the implementations differ. I have been tolkd int he past by elogind upstream that it is not possible for elogind to use libsystemd0. For example libsystemd0 requires the concept of slices which elogind doesn't have. The only way I have got all of these components to work together on an elogind systemd is to ensure everything uses libelogind0. Can't this be stubbed or mocked on the elogind side?
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
On Fri, Sep 20, 2019 at 09:06:57AM +0200, Laurent Bigonville wrote: > Hello, > > When I looked I elogind a while back I was able to build a package without > having a public libelogind0, I basically had that in my debian/rules file: > > # We only build the libelogind0 and libelogind-dev if we are building for > # Devuan or its derivatives > ifneq ($(shell dpkg-vendor --derives-from Devuan && yes), yes) > export DH_OPTIONS=--no-package=libelogind0 --no-package=libelogind-dev > endif > > libelogind library is only needed for applications that want to interact > with the daemon, in the ITP (#905388) bug I also noted that. > > If I'm not mistaken, libsystemd (and libelogind) are using D-Bus to > communicate with the daemon part, was it checked that the API used is > compatible? Is there documentation of the differences, if any? Yes, the APIs are the same (deliberately so). > Bottom line, is libelogind even needed in the archive to achieve your goal > of having an implementation of the login1 D-Bus API not requiring systemd as > PID1? Thanks. I think you are correct that the login1 DBus API doesn't require libsystemd0 or libelogind0. However some packages, notably policykit use the sd-login(3) API which is part of libsystemd0 or libelogind0. Whilst the APIs, and symbol ABIs are the same between the two libraries (with the caveats noted in the libelogind0 package description) the implementations differ. I have been tolkd int he past by elogind upstream that it is not possible for elogind to use libsystemd0. For example libsystemd0 requires the concept of slices which elogind doesn't have. The only way I have got all of these components to work together on an elogind systemd is to ensure everything uses libelogind0. Mark
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
On Fri, Sep 20, 2019 at 09:06:57AM +0200, Laurent Bigonville wrote: > When I looked I elogind a while back I was able to build a package without > having a public libelogind0, I basically had that in my debian/rules file: > > # We only build the libelogind0 and libelogind-dev if we are building for > # Devuan or its derivatives > ifneq ($(shell dpkg-vendor --derives-from Devuan && yes), yes) > export DH_OPTIONS=--no-package=libelogind0 --no-package=libelogind-dev > endif That was the case initially, yes. It might be worth going back to. > libelogind library is only needed for applications that want to interact > with the daemon, in the ITP (#905388) bug I also noted that. > > If I'm not mistaken, libsystemd (and libelogind) are using D-Bus to > communicate with the daemon part, was it checked that the API used is > compatible? Is there documentation of the differences, if any? The API and dbus protocol are compatible (or at least are supposed to be). However, per the request of policykit's maintainer, libelogind was instead made ABI-compatible with libsystemd, and was made to replace it. > Bottom line, is libelogind even needed in the archive to achieve your goal > of having an implementation of the login1 D-Bus API not requiring systemd as > PID1? This approach was used until February, and did work well. I'm a mere user/sponsor thus I don't fully understand the reasons for switching. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, ⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month. ⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake, ⠈⠳⣄ etc), let the drink age at least 3-6 months.
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
Hello, When I looked I elogind a while back I was able to build a package without having a public libelogind0, I basically had that in my debian/rules file: # We only build the libelogind0 and libelogind-dev if we are building for # Devuan or its derivatives ifneq ($(shell dpkg-vendor --derives-from Devuan && yes), yes) export DH_OPTIONS=--no-package=libelogind0 --no-package=libelogind-dev endif libelogind library is only needed for applications that want to interact with the daemon, in the ITP (#905388) bug I also noted that. If I'm not mistaken, libsystemd (and libelogind) are using D-Bus to communicate with the daemon part, was it checked that the API used is compatible? Is there documentation of the differences, if any? Bottom line, is libelogind even needed in the archive to achieve your goal of having an implementation of the login1 D-Bus API not requiring systemd as PID1? my 2¢
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
Julien, Thank you. On Wed, Sep 11, 2019 at 02:48:19PM +0200, Julien Cristau wrote: > -UID: 41176 > > Package: libelogind0 > Version: 241.3-1+debian1 > Severity: serious > > I wrote this in #934132 but that is being ignored so I'll repeat here. I don't think it was being ignored, rather I had already answered it there. > I don't think it's reasonable to ship this package with C/R/P > libsystemd0. I understand that you don't like it. However, for libelogind0 to export the same symbols as libsystemd0 so that it could C/R/P libsystemd0 was the agreed solution to bug #923244. Do you have another suggestion as to how we could have resolved that? Other solutions were discounted at the time. > I think it opens you (and, more importantly, users) up to issues like > #934491. Even if #935910 were to be fixed in the package manager in > > > bullseye, it would still mean libelogind0 couldn't ship with the C/R/P > until bullseye+1. I think it seems likely from discussions on #debian-dpkg that #935910 will be fixed in APT and #934491 can be addressed by adding Breaks: << fixed APT. > But beyond that particular issue, I'm sorry to say I think fundamentally > attempting to provide a drop-in replacement for libsystemd0 while > conflicting with systemd is doomed. The replacement of sysvinit with > systemd was careful to keep both init systems co-installable, and I > think that's something to preserve to avoid providing users with a > loaded footgun with alternative init systems. I think this is where we will just have to disagree. I think choice in software is important. That choice is precious and can be exercised in many ways. Most importantly, you are free to choose not to use something that you don't like or don't want. Best wishes Mark
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
Hello Julien, > conflicting with systemd is doomed. The replacement of sysvinit with > systemd was careful to keep both init systems co-installable, and I note that: ① elogind is not part of the init system, only an add-on to enable systemd-like Provides to get some GUI software to run without resorting to using consolekit (which is only available from older versions of Debian) ② systemd currently is the one that isn’t coinstallable (cf. #935304) > think that's something to preserve to avoid providing users with a > loaded footgun with alternative init systems. This is about an alternative logind implementation, which happens to be usable with an “alternative” init system. But what do you propose instead? Also, question back: could elogind work with libsystemd0, and could elogind work with systemd (although while this would address the issue of switching, not Conflicting with systemd increases the chance that elogind is installed by accident, which people also don’t want)? bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg ** Mit der tarent Academy bieten wir auch Trainings und Schulungen in den Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an. Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt. **
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
Package: libelogind0 Version: 241.3-1+debian1 Severity: serious I wrote this in #934132 but that is being ignored so I'll repeat here. I don't think it's reasonable to ship this package with C/R/P libsystemd0. I think it opens you (and, more importantly, users) up to issues like #934491. Even if #935910 were to be fixed in the package manager in bullseye, it would still mean libelogind0 couldn't ship with the C/R/P until bullseye+1. But beyond that particular issue, I'm sorry to say I think fundamentally attempting to provide a drop-in replacement for libsystemd0 while conflicting with systemd is doomed. The replacement of sysvinit with systemd was careful to keep both init systems co-installable, and I think that's something to preserve to avoid providing users with a loaded footgun with alternative init systems. Cheers, Julien
