Re: Upgrade package from init script to Systemd, move config folder
On Thu, Apr 27, 2023 at 10:54:58AM +0200, Marc Haber wrote: > On Thu, 27 Apr 2023 08:20:34 +0200, Simon Richter > wrote: > >On Wed, Apr 26, 2023 at 04:25:19PM +0200, Marc Haber wrote: > >> I am not sure whether it is doing non-systemd users a favor to keep a > >> probably outdated, bitrotting and untested init script in the > >> canonical place. My gut feeling is that it might be better to ship the > >> old init script in /usr/share/doc/package/examples unless the package > >> maintainer is reasonably sure that the init script will actually work. > > > >No, that is worse, because if an updated init script is shipped as an > >example only, I will not even get a notification that I might want to > >change my installed init script. > > You have a point here. Maybe it would be a good idea to have a > standardized function in /lib/lsb/init-functions that emits a warning > that the package maintainer has changed the mechanism to invoke the > daemon and that the init script might need additional work, so that a > lazy maintainer like me might just call that function to give the > local admin a heads-up. If systemd runs as init, I do not think such a warning is needed, since trying to run /etc/init.d/foo will be transparently redirected to an invocation of the (supposedly maintained) systemd service (unless, of course, somebody explicitly performs the incantation to really, really run the SysV init script, in which case I would assume they know what they are doing, and also see the next point). If sysv-init runs as init, then I'm not sure such a warning at each invocation of the init script would actually be useful: first, it might be missed, and second, the admin may (consciously or not) learn to ignore it. I think a one-time notification via a (Debian) NEWS entry would be a better choice. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Re: Upgrade package from init script to Systemd, move config folder
On Thu, 27 Apr 2023 08:20:34 +0200, Simon Richter wrote: >On Wed, Apr 26, 2023 at 04:25:19PM +0200, Marc Haber wrote: >> I am not sure whether it is doing non-systemd users a favor to keep a >> probably outdated, bitrotting and untested init script in the >> canonical place. My gut feeling is that it might be better to ship the >> old init script in /usr/share/doc/package/examples unless the package >> maintainer is reasonably sure that the init script will actually work. > >No, that is worse, because if an updated init script is shipped as an >example only, I will not even get a notification that I might want to >change my installed init script. You have a point here. Maybe it would be a good idea to have a standardized function in /lib/lsb/init-functions that emits a warning that the package maintainer has changed the mechanism to invoke the daemon and that the init script might need additional work, so that a lazy maintainer like me might just call that function to give the local admin a heads-up. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Upgrade package from init script to Systemd, move config folder
On Thu, Apr 27, 2023 at 09:02:38AM +0800, Paul Wise wrote: > On Wed, 2023-04-26 at 22:44 +0300, Boian Bonev wrote: > > > OTOH it is an un-favor to move or remove it > ... > > It is better to keep the init script in place. Absolutely. > Another option is the orphan-sysvinit-scripts package: Which is still the second best option. Despite Matthew's best efforts, having the init script in a separate package causes several issues. See Bugs/Limitations in the orphan-sysvinit-scripts README[1]. Please leave the init script in place. Mark [1] https://salsa.debian.org/matthew/orphan-sysvinit-scripts/-/blob/master/README.org -- Mark Hindley GPG: 506C 15A4 2B0A F5A0 A854 23EE D28A 45BF 3287 D649
Re: Upgrade package from init script to Systemd, move config folder
Hi, On Wed, Apr 26, 2023 at 04:25:19PM +0200, Marc Haber wrote: > I am not sure whether it is doing non-systemd users a favor to keep a > probably outdated, bitrotting and untested init script in the > canonical place. My gut feeling is that it might be better to ship the > old init script in /usr/share/doc/package/examples unless the package > maintainer is reasonably sure that the init script will actually work. No, that is worse, because if an updated init script is shipped as an example only, I will not even get a notification that I might want to change my installed init script. Simon
Re: Upgrade package from init script to Systemd, move config folder
On Wed, 2023-04-26 at 22:44 +0300, Boian Bonev wrote: > OTOH it is an un-favor to move or remove it ... > It is better to keep the init script in place. Another option is the orphan-sysvinit-scripts package: Description: Orphaned System-V-like init scripts This package provides System-V init scripts for packages whose maintainers have chosen to drop them from the distribution in favour of only supplying a systemd service file. . It will only put files into /etc/init.d/ when the relevant package is installed on your system. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Upgrade package from init script to Systemd, move config folder
Hi, On Wed, 2023-04-26 at 16:25 +0200, Marc Haber wrote: > On Mon, 24 Apr 2023 15:48:02 +0100, Matthew Vernon > wrote: > > One thing I'd say is: please keep the init script in your package, > > so that people using inits other than systemd can continue to use > > it. > > I am not sure whether it is doing non-systemd users a favor to keep a > probably outdated, bitrotting and untested init script in the > canonical place. OTOH it is an un-favor to move or remove it, no matter if it is half- working or completely non-working. For a less experienced user it will be easier to fix a half-/non-working script in place than to look for it in obscure places, copy it from another distro or get it from a magic 'curl http... | sh' link. > My gut feeling is that it might be better to ship the old init script > in /usr/share/doc/package/examples unless the package maintainer is > reasonably sure that the init script will actually work. It is better to keep the init script in place. That will not affect systemd users in any way, besides <1k in disk space (same as with /usr/share/doc/package/examples). Also in case the maintainer is not interested in the init script, then the task for keeping the init script in good order should be left to those interested on a best effort basis. Who cares if a package ships a 100% bit-rotten init script? Only the people who use that un-popular init system. Then let them fix it. On the maintainer side - how much does it hurt to occasionally accept a patch for a small file? It would have been much easier if dpkg did allow to declare in package B that package A depends on B and in case A is removed then B should also go (to name it precisely, the relation is supplement)... Unlike sysvinit upstart is obsolete and removing upstart configuration is a good thing. But that is not the case with sysvinit. Removing the init scripts really hurts a group of people. Compared to Debian's user base that group is very very small. But tell me how small is a good number to be 'safely' ignored/neglected? 100, 1000 or 1? With best regards, b.
Re: Upgrade package from init script to Systemd, move config folder
On Mon, 24 Apr 2023 15:48:02 +0100, Matthew Vernon wrote: >One thing I'd say is: please keep the init script in your package, so >that people using inits other than systemd can continue to use it. I am not sure whether it is doing non-systemd users a favor to keep a probably outdated, bitrotting and untested init script in the canonical place. My gut feeling is that it might be better to ship the old init script in /usr/share/doc/package/examples unless the package maintainer is reasonably sure that the init script will actually work. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Upgrade package from init script to Systemd, move config folder
Hi, Perry Naseck writes: > I am in the process of updating/upgrading a package from an init.d service > to a Systemd service. Are there any recommended guidelines for this process? > > Looking through some current packages I see that a lot of them have both an > init script and a Systemd service in their debian folder. Do > dh_installsystemd and dh_installinit handle this smoothly by default if both > files exist? When upgrading the package on a machine will it stop the init > service and start the Systemd service? Assuming your unit file and init script have the same name, then yes. One thing I'd say is: please keep the init script in your package, so that people using inits other than systemd can continue to use it. Thanks, Matthew -- "At least you know where you are with Microsoft." "True. I just wish I'd brought a paddle." http://www.debian.org
Re: Upgrade package from init script to Systemd, move config folder
On 4/20/23 14:48, Perry Naseck wrote: Hello! I am in the process of updating/upgrading a package from an init.d service to a Systemd service. Are there any recommended guidelines for this process? My generic advice would be: start your thinking from a perspective of "how should this work in systemd anew", not "how do I 1:1 convert the init.d unit". That is, start in a "systemd native" approach. You may need to pull back from that for backwards compatibility reasons, or consistency with the init.d unit or whatever (and I maintain a package that is that way), but make those decisions intentionally. Looking through some current packages I see that a lot of them have both an init script and a Systemd service in their debian folder. Do dh_installsystemd and dh_installinit handle this smoothly by default if both files exist? In my experience, if the files are name the same (i.e. /etc/init.d/foo and /lib/systemd/system/foo.service), everything should Just Work, both in terms of the Debian bits and the systemd bits (discussed below). When upgrading the package on a machine will it stop the init service and start the Systemd service? There is no such thing as an "init service" on a systemd machine. If you have only /etc/init.d/foo, systemd is dynamically generating a foo.service unit. You can see this with e.g. "systemctl status foo". For example, on my system: $ systemctl status openipmi × openipmi.service - LSB: OpenIPMI Driver init script Loaded: loaded (/etc/init.d/openipmi; generated) When you install a foo.service unit file, that will take precedence over the generated one. So (assuming they have the same name), they are the same service. This package also stores its configuration in /var/lib/packagename and it should really be in /etc/packagename. Where is the best place to deal with auto-migration? Should this go in postinst or is there a debhelper that I should use? Take this with a grain of salt, and defer to more knowledgeable folks, but... If I were in that situation, I'd start with the idea of moving it in a preinst script. I would probably also guard it with version checks (as opposed to only checks for the existence of the folder). So something like (where the "2" in version-2~ is the package version one _higher_ than the version where you made the change, i.e. if you changed in -1, use -2~): #!/bin/sh set -e if [ "$1" = "upgrade" ] && [ -n "$2" ] then if dpkg --compare-versions "$2" le-nl "version-2~" then if [ -e /var/lib/packagename ] && ! [ -e /etc/packagename ] then mv /var/lib/packagename /etc/packagename fi fi fi That said, I'm not sure what Policy has to say about this. It seems to me that you want the package to do things right moving forward, and you want to support clean upgrades, so this seems like the approach that gets both of those. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Upgrade package from init script to Systemd, move config folder
Hello! I am in the process of updating/upgrading a package from an init.d service to a Systemd service. Are there any recommended guidelines for this process? Looking through some current packages I see that a lot of them have both an init script and a Systemd service in their debian folder. Do dh_installsystemd and dh_installinit handle this smoothly by default if both files exist? When upgrading the package on a machine will it stop the init service and start the Systemd service? The original config, postinst, and init script also configure some debconf values that are not needed anymore. What is the best way to remove those settings without depending on the debconf package? This package also stores its configuration in /var/lib/packagename and it should really be in /etc/packagename. Where is the best place to deal with auto-migration? Should this go in postinst or is there a debhelper that I should use? Thanks! Perry Naseck
