Bug#1016021: debhelper: Please change generated tmpfiles misc:Depends to systemd-standalone-tmpfiles | systemd-tmpfiles
Ansgar, On Wed, Aug 03, 2022 at 11:01:53AM +0200, Ansgar wrote: > On Wed, 2022-08-03 at 09:27 +0100, Mark Hindley wrote: > > On Wed, Aug 03, 2022 at 10:11:29AM +0200, Michael Biebl wrote: > > > > > > No, that would be a bad idea since systemd already ships its own, > > > preferred implementation. > > > > Is there a difference between the built-in and standalone > > implementation other than the packaging? > > Yes, executable size for example. > > A reasonable alternative to include container user needs better might > be to require init systems to provide tmpfiles (i.e., depend on a > implementation) and packages to not depend on it if they only use > tmpfiles if required for service startup via the system service > manager. (I'm not sure if tmpfiles are always used this way.) This seems an interesting idea. I wonder if it could be handled in the init metapackage from src:init-script-helpers? Mark
Bug#1016021: debhelper: Please change generated tmpfiles misc:Depends to systemd-standalone-tmpfiles | systemd-tmpfiles
On Wed, 2022-08-03 at 09:27 +0100, Mark Hindley wrote: > On Wed, Aug 03, 2022 at 10:11:29AM +0200, Michael Biebl wrote: > > > > No, that would be a bad idea since systemd already ships its own, > > preferred implementation. > > Is there a difference between the built-in and standalone > implementation other than the packaging? Yes, executable size for example. A reasonable alternative to include container user needs better might be to require init systems to provide tmpfiles (i.e., depend on a implementation) and packages to not depend on it if they only use tmpfiles if required for service startup via the system service manager. (I'm not sure if tmpfiles are always used this way.) That way people who start services directly in a init-less container would not require a tmpfiles implementation to be installed, but would have to perfor undocumented extra steps (but that's not really a change if one does not use the system-provided startup configuration). Sadly such container usage conflicts with the sysvinit maintainers position that packages should explicitly depend on specific init systems :( Ansgar
Bug#1016021: debhelper: Please change generated tmpfiles misc:Depends to systemd-standalone-tmpfiles | systemd-tmpfiles
Michael, Thanks. On Wed, Aug 03, 2022 at 10:11:29AM +0200, Michael Biebl wrote: > > I have an alternative approach that I would be grateful for your thoughts > > and > > opinion on: all packages (systemd included) use the > > systemd-standalone-tmpfiles > > implementation and that is the dependency that debhelper generates if a > > tmpfiles > > snippet is present. > > > > What do you think? > > No, that would be a bad idea since systemd already ships its own, preferred > implementation. Is there a difference between the built-in and standalone implementation other than the packaging? > We won't penalize systemd users I wouldn't want to penalize anybody. Thanks and best wishes Mark
Bug#1016021: debhelper: Please change generated tmpfiles misc:Depends to systemd-standalone-tmpfiles | systemd-tmpfiles
Am 03.08.22 um 10:06 schrieb Mark Hindley: Ansgar and Michael, On Wed, Aug 03, 2022 at 09:12:04AM +0200, Ansgar wrote: I assume this is the result of running debootstrap with --include systemd-standalone-tmpfiles? No, I changed the dependencies of one of the involved packages to the one suggested. But it has the same effect as an explicit --include, i.e., it resulted in debootstrap trying to install systemd-standalone- tmpfiles. Thanks. There continues to be a slow drip of end-user bug reports generated by this issue. I have an alternative approach that I would be grateful for your thoughts and opinion on: all packages (systemd included) use the systemd-standalone-tmpfiles implementation and that is the dependency that debhelper generates if a tmpfiles snippet is present. What do you think? No, that would be a bad idea since systemd already ships its own, preferred implementation. We won't penalize systemd users simply because the sysvinit maintainers for no good reason don't want to add a Recommends/Depends on the standalone implementation. OpenPGP_signature Description: OpenPGP digital signature
Bug#1016021: debhelper: Please change generated tmpfiles misc:Depends to systemd-standalone-tmpfiles | systemd-tmpfiles
Ansgar and Michael, On Wed, Aug 03, 2022 at 09:12:04AM +0200, Ansgar wrote: > > I assume this is the result of running debootstrap with --include > > systemd-standalone-tmpfiles? > > No, I changed the dependencies of one of the involved packages to the > one suggested. But it has the same effect as an explicit --include, > i.e., it resulted in debootstrap trying to install systemd-standalone- > tmpfiles. Thanks. There continues to be a slow drip of end-user bug reports generated by this issue. I have an alternative approach that I would be grateful for your thoughts and opinion on: all packages (systemd included) use the systemd-standalone-tmpfiles implementation and that is the dependency that debhelper generates if a tmpfiles snippet is present. What do you think? Best wishes Mark
Bug#1016021: debhelper: Please change generated tmpfiles misc:Depends to systemd-standalone-tmpfiles | systemd-tmpfiles
On Wed, 2022-07-27 at 07:14 +0100, Mark Hindley wrote: > On Mon, Jul 25, 2022 at 09:02:09PM +0200, Ansgar wrote: > > On Mon, 25 Jul 2022 13:05:02 +0100 Mark Hindley wrote: > > > It has been suggested that changing the dependency to > > > > > > systemd-standalone-tmpfiles | systemd-tmpfiles > > > > > > would help the packaging system usually find the correct solution and > > > reduce the > > > number of unexpected surprises users are reporting. > > > > This change breaks debootstrap as expected: > > > > +--- > > > W: Failure while installing base packages. This will be re-attempted up > > > to five times. > > > W: See /tmp/u/unstable/debootstrap/debootstrap.log for details (possibly > > > the package > > > /var/cache/apt/archives/systemd-standalone-tmpfiles_251.3-1_amd64.deb is > > > at fault) > > +--- > > > > I hope this addresses the question for "evidence and rationale of this > > concern" why I say this is problematic. > > I assume this is the result of running debootstrap with --include > systemd-standalone-tmpfiles? No, I changed the dependencies of one of the involved packages to the one suggested. But it has the same effect as an explicit --include, i.e., it resulted in debootstrap trying to install systemd-standalone- tmpfiles. Ansgar
Bug#1016021: debhelper: Please change generated tmpfiles misc:Depends to systemd-standalone-tmpfiles | systemd-tmpfiles
Control: close -1 Ansgar, On Mon, Jul 25, 2022 at 09:02:09PM +0200, Ansgar wrote: > On Mon, 25 Jul 2022 13:05:02 +0100 Mark Hindley wrote: > > It has been suggested that changing the dependency to > > > > systemd-standalone-tmpfiles | systemd-tmpfiles > > > > would help the packaging system usually find the correct solution and > > reduce the > > number of unexpected surprises users are reporting. > > This change breaks debootstrap as expected: > > +--- > | W: Failure while installing base packages. This will be re-attempted up to > five times. > | W: See /tmp/u/unstable/debootstrap/debootstrap.log for details (possibly > the package > /var/cache/apt/archives/systemd-standalone-tmpfiles_251.3-1_amd64.deb is at > fault) > +--- > > I hope this addresses the question for "evidence and rationale of this > concern" why I say this is problematic. I assume this is the result of running debootstrap with --include systemd-standalone-tmpfiles? > > With this change, on a systemd installation the dependency would already be > > satisfied and therefore noop for APT. For installations without systemd, be > > that > > systems using other inits or in containers, APT would choose the standalone > > implementation. > > You state this as a fact, but it is sadly false. See prior discussions > about systemd-shim which had similar problems and caused various > problems even after removal from the archive (because conffiles). (I'm > too lazy to look this up for another repeat of this argument, after all > it is your claim; I already wasted too much time on the test above.) I am sorry that my lack of experience and familiarity with the internals and history of debootstrap causes such exasperation to you. Perhaps you could find a way to disseminate your considerable knowledge and experience in a more graceful way? Thanks anyway. I withdraw my suggestion. Best wishes. Mark
Bug#1016021: debhelper: Please change generated tmpfiles misc:Depends to systemd-standalone-tmpfiles | systemd-tmpfiles
On Tue, 2022-07-26 at 10:49 +0100, Mark Hindley wrote: > Luca, > > [Sorry for the slow reply, your response was not sent to me.] > > On Mon, Jul 25, 2022 at 04:52:32PM +0100, Luca Boccassi wrote: > > Indeed it would be wrong. Also the justification doesn't seem correct: > > simply installing the 'systemd' binary does NOT switch the init system, > > so it's difficult to see how it could 'significant problems' in and by > > itself. > > I know that the original intention was to allow installation of the systemd > binary independently of switching the init system. Whilst, in theory, that is > still the case, in many, perhaps most real-world situations, installation of > systemd does force a change of init. This is because the two available logind > implementations (and therefore their dependency chains: > libpam-systemd->systemd > or libpam-elogind->elogind) conflict and libpam-systemd depends on > systemd-sysv. So, when installing just the systemd binary on a system which > uses > a non-systemd init and the libpam-elogind logind implementation, APT has to > change to libpam-systemd which pulls in systemd-sysv and forces the init > switch. > > Logind dependencies are now very widespread. With packages such as > openssh-server having a Recommends for it, even relatively minimal server > installations will often require a logind implementation. > > I hope that explanation is clear and helps. The systemd binary package does not depend on libpam-systemd, that is not the issue. Installing it does not pull in libpam nor switches the init system What you are referring to happens because elogind conflicts with systemd, so obviously the systemd package and the elogind package cannot be installed at the same time. That sounds like something that should be fixed in elogind, and not a reason to make the default use case more risky. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1016021: debhelper: Please change generated tmpfiles misc:Depends to systemd-standalone-tmpfiles | systemd-tmpfiles
Luca, [Sorry for the slow reply, your response was not sent to me.] On Mon, Jul 25, 2022 at 04:52:32PM +0100, Luca Boccassi wrote: > Indeed it would be wrong. Also the justification doesn't seem correct: > simply installing the 'systemd' binary does NOT switch the init system, > so it's difficult to see how it could 'significant problems' in and by > itself. I know that the original intention was to allow installation of the systemd binary independently of switching the init system. Whilst, in theory, that is still the case, in many, perhaps most real-world situations, installation of systemd does force a change of init. This is because the two available logind implementations (and therefore their dependency chains: libpam-systemd->systemd or libpam-elogind->elogind) conflict and libpam-systemd depends on systemd-sysv. So, when installing just the systemd binary on a system which uses a non-systemd init and the libpam-elogind logind implementation, APT has to change to libpam-systemd which pulls in systemd-sysv and forces the init switch. Logind dependencies are now very widespread. With packages such as openssh-server having a Recommends for it, even relatively minimal server installations will often require a logind implementation. I hope that explanation is clear and helps. Best wishes Mark
Bug#1016021: debhelper: Please change generated tmpfiles misc:Depends to systemd-standalone-tmpfiles | systemd-tmpfiles
On Mon, 25 Jul 2022 13:05:02 +0100 Mark Hindley wrote: > It has been suggested that changing the dependency to > > systemd-standalone-tmpfiles | systemd-tmpfiles > > would help the packaging system usually find the correct solution and reduce > the > number of unexpected surprises users are reporting. This change breaks debootstrap as expected: +--- | W: Failure while installing base packages. This will be re-attempted up to five times. | W: See /tmp/u/unstable/debootstrap/debootstrap.log for details (possibly the package /var/cache/apt/archives/systemd-standalone-tmpfiles_251.3-1_amd64.deb is at fault) +--- I hope this addresses the question for "evidence and rationale of this concern" why I say this is problematic. > With this change, on a systemd installation the dependency would already be > satisfied and therefore noop for APT. For installations without systemd, be > that > systems using other inits or in containers, APT would choose the standalone > implementation. You state this as a fact, but it is sadly false. See prior discussions about systemd-shim which had similar problems and caused various problems even after removal from the archive (because conffiles). (I'm too lazy to look this up for another repeat of this argument, after all it is your claim; I already wasted too much time on the test above.) We also had the very same discussion about dependency ordering for libpam-systemd (or default-logind these days). I don't see any substantial difference here to handle it differently. I don't think we should make dependencies more brittle by not following the policy to list the preferred package first; exploring alternatives can be done w/o doing so. Ansgar
Bug#1016021: debhelper: Please change generated tmpfiles misc:Depends to systemd-standalone-tmpfiles | systemd-tmpfiles
On Mon, 25 Jul 2022 18:11:21 +0100 Mark Hindley wrote: > Michael, > > Thanks for this. > > On Mon, Jul 25, 2022 at 04:08:28PM +0200, Michael Biebl wrote: > > Am 25.07.22 um 14:05 schrieb Mark Hindley: > > > > > It has been suggested that changing the dependency to > > > > > > systemd-standalone-tmpfiles | systemd-tmpfiles > > > > > > would help the packaging system usually find the correct solution and reduce the > > > number of unexpected surprises users are reporting. > > > > > > With this change, on a systemd installation the dependency would already be > > > satisfied and therefore noop for APT. > > > > This is not correct. It would make the bootstrap phase more brittle as > > outlined by ansgar. So this is certainly a no-go. > > I am afraid I can't find any detail of this beyond Ansgar's statement of this as > fact[1]. Could you point me to the evidence and rationale of this concern, > please? It's very simple: the default is intentionally, and must remain, to install the systemd package to provide those utilities, because that's what gets the widest usage and the most testing. The alternatives are provided as a courtesy, as optional alternatives for non-default use cases, and are seldomly used and lightly tested. > > I hate to repeat myself: add a Recommends or Depends on > > systemd-standalone-tmpfiles to sysvinit-core to help apt choose the right > > solution for such non-standard configurations. > > I also hate to repeat myself, but sysvinit-core makes no use of tmpfiles, > therefore to add the dependency there would be incorrect and an abuse of the > packaging system. Dependencies can and are used to influence the behaviour of the installed system all the time, it is not true that there must always be a direct 1:1 mapping between a dependency and an artifact being directly used. We have metapackages all over the places after all. But even then, if you don't want that use a Recommends instead, or create a new meta-package that you own and sets the preferences as you see fit, or change the build scripts to use --include/--exclude, or have post- build processing scripts to change the list of installed packages, and so on. Or simply leave the systemd package installed, as by itself it does nothing given the init system is not changed by simply having it installed by itself, so there's no functional difference. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1016021: debhelper: Please change generated tmpfiles misc:Depends to systemd-standalone-tmpfiles | systemd-tmpfiles
Michael, On Mon, Jul 25, 2022 at 04:14:26PM +0200, Michael Biebl wrote: > Fwiw, if there is no interest from the sysvinit camp to use the standalone > versions, I'll probably drop them again in one of the next uploads. Judging by the recent bugs on the issue, there is considerable interest within the community in the standalone packages. Mark
Bug#1016021: debhelper: Please change generated tmpfiles misc:Depends to systemd-standalone-tmpfiles | systemd-tmpfiles
Michael, Thanks for this. On Mon, Jul 25, 2022 at 04:08:28PM +0200, Michael Biebl wrote: > Am 25.07.22 um 14:05 schrieb Mark Hindley: > > > It has been suggested that changing the dependency to > > > > systemd-standalone-tmpfiles | systemd-tmpfiles > > > > would help the packaging system usually find the correct solution and > > reduce the > > number of unexpected surprises users are reporting. > > > > With this change, on a systemd installation the dependency would already be > > satisfied and therefore noop for APT. > > This is not correct. It would make the bootstrap phase more brittle as > outlined by ansgar. So this is certainly a no-go. I am afraid I can't find any detail of this beyond Ansgar's statement of this as fact[1]. Could you point me to the evidence and rationale of this concern, please? > I hate to repeat myself: add a Recommends or Depends on > systemd-standalone-tmpfiles to sysvinit-core to help apt choose the right > solution for such non-standard configurations. I also hate to repeat myself, but sysvinit-core makes no use of tmpfiles, therefore to add the dependency there would be incorrect and an abuse of the packaging system. In general, adding incorrect and spurious dependencies actually makes APT's job more difficult. And this proposal would have no benefit for users of other init systems. And it would not help people who are finding systemd pulled into their minimal containers[2]. Best wishes Mark [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014805#24 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014805#35
Bug#1016021: debhelper: Please change generated tmpfiles misc:Depends to systemd-standalone-tmpfiles | systemd-tmpfiles
On Mon, 25 Jul 2022 16:08:28 +0200 Michael Biebl wrote: > Am 25.07.22 um 14:05 schrieb Mark Hindley: > > > It has been suggested that changing the dependency to > > > > systemd-standalone-tmpfiles | systemd-tmpfiles > > > > would help the packaging system usually find the correct solution and reduce the > > number of unexpected surprises users are reporting. > > > > With this change, on a systemd installation the dependency would already be > > satisfied and therefore noop for APT. > > This is not correct. It would make the bootstrap phase more brittle as > outlined by ansgar. So this is certainly a no-go. Indeed it would be wrong. Also the justification doesn't seem correct: simply installing the 'systemd' binary does NOT switch the init system, so it's difficult to see how it could 'significant problems' in and by itself. > I hate to repeat myself: add a Recommends or Depends on > systemd-standalone-tmpfiles to sysvinit-core to help apt choose the > right solution for such non-standard configurations. On top of that, when building images debootstrap provides --include/-- exclude switches to also do that. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1016021: debhelper: Please change generated tmpfiles misc:Depends to systemd-standalone-tmpfiles | systemd-tmpfiles
Am 25.07.22 um 16:08 schrieb Michael Biebl: Am 25.07.22 um 14:05 schrieb Mark Hindley: It has been suggested that changing the dependency to systemd-standalone-tmpfiles | systemd-tmpfiles would help the packaging system usually find the correct solution and reduce the number of unexpected surprises users are reporting. With this change, on a systemd installation the dependency would already be satisfied and therefore noop for APT. This is not correct. It would make the bootstrap phase more brittle as outlined by ansgar. So this is certainly a no-go. I hate to repeat myself: add a Recommends or Depends on systemd-standalone-tmpfiles to sysvinit-core to help apt choose the right solution for such non-standard configurations. Fwiw, if there is no interest from the sysvinit camp to use the standalone versions, I'll probably drop them again in one of the next uploads. OpenPGP_signature Description: OpenPGP digital signature
Bug#1016021: debhelper: Please change generated tmpfiles misc:Depends to systemd-standalone-tmpfiles | systemd-tmpfiles
Am 25.07.22 um 14:05 schrieb Mark Hindley: It has been suggested that changing the dependency to systemd-standalone-tmpfiles | systemd-tmpfiles would help the packaging system usually find the correct solution and reduce the number of unexpected surprises users are reporting. With this change, on a systemd installation the dependency would already be satisfied and therefore noop for APT. This is not correct. It would make the bootstrap phase more brittle as outlined by ansgar. So this is certainly a no-go. I hate to repeat myself: add a Recommends or Depends on systemd-standalone-tmpfiles to sysvinit-core to help apt choose the right solution for such non-standard configurations. OpenPGP_signature Description: OpenPGP digital signature
Bug#1016021: debhelper: Please change generated tmpfiles misc:Depends to systemd-standalone-tmpfiles | systemd-tmpfiles
Package: debhelper Version: 13.8 Severity: normal Niels, Currently, debhelper generates systemd | systemd-tmpfiles as the misc:Depends when a tmpfiles implementation is required. However, that is causing significant problems for a number of users of non-systemd systems and in containers when APT chooses the first option[1][2]. It has been suggested that changing the dependency to systemd-standalone-tmpfiles | systemd-tmpfiles would help the packaging system usually find the correct solution and reduce the number of unexpected surprises users are reporting. With this change, on a systemd installation the dependency would already be satisfied and therefore noop for APT. For installations without systemd, be that systems using other inits or in containers, APT would choose the standalone implementation. Thanks and best wishes Mark -- System Information: Debian Release: bookworm/sid Architecture: amd64 (x86_64) Kernel: Linux 5.18.0-2-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages debhelper depends on: ii autotools-dev20220109.1 ii dh-autoreconf20 ii dh-strip-nondeterminism 1.13.0-1 ii dpkg 1.21.9 ii dpkg-dev 1.21.9 ii dwz 0.14-1 ii file 1:5.41-4 ii libdebhelper-perl13.8 ii libdpkg-perl 1.21.9 ii man-db 2.10.2-1 ii perl 5.34.0-5 ii po-debconf 1.0.21+nmu1 debhelper recommends no packages. Versions of packages debhelper suggests: pn dh-make -- no debconf information [1] https://bugs.debian.org/1016006 [2] https://bugs.debian.org/1014805
