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

<div dir="ltr"><div>Hello!</div><div><br></div><div>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?</div><div><br></div><div>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?</div><div><br></div><div>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?<br></div><div><br></div><div>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?</div><div><br></div><div>Thanks!<br></div><div>Perry Naseck<br></div></div>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

Perry Naseck <[email protected]> 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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 24 Apr 2023 15:48:02 +0100, Matthew Vernon
<[email protected]> 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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

On Wed, 2023-04-26 at 16:25 +0200, Marc Haber wrote:

On Mon, 24 Apr 2023 15:48:02 +0100, Matthew Vernon
<[email protected]> 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 10000?

With best regards,
b.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEYQsotVz8/kXqG1Y7MRa6Xp/6aaMFAmRJya4ACgkQMRa6Xp/6 aaPlsw//R5LkjGJKNvp/Hy6wk9I0tlMyF7xvKNpg9dW3a6cezOmscmYS/6d7WzHf LBOhSGzt+dSiY6GWhOBTwwOg/VPftRgUJTpBmUR7DS+sPj5fwKZOQdp92o0/A0lr Mhod0koATeaw6HQZBQMsFKrAFhOx2XrRzULp4QulWL35RIpaE+G6aWdX6X3iKcIT rSXuKrFYQECbAluDPTNKNbKMKremKT6rY8AjF+lkYQaH6EJUrjtRjI+I+cLv8f6W ePXOI5dap3N+PVFr58Y13WWOU55YenN+vmREA4PverPMly9iJaSPayTzaCjXvjb7 6mWUu7hX+EoILTNJHe5xFzBrGQV/0Pnx/LERH4aDGAblre53vzcIqSDvAp/wStMS UoQxRyjIZW0yyGGnuNtS5TXOxIBtUZhJvgOeXw7Ab1r7rUlu2V+ervheMMCIhDLc m6Ke6l73FhNqPg+LwUdNkINT/b4WLzwtstjoqjK2WO3VCAUS7+7yTe0w5rcwfO91 ZcRlXNu54hoF1KFMBFgnZ0KEySz4EkT8XEUJMSL63PfVKSTTWTId5itPV9okdAPW as48RXlTEzzhXOEVnpn1u7vOyEoxadyqKx768X/yPV4GPrARss99vSOu/skzjyQ7 LcnZRiZhHX1i+ttD+VF+nB84grK8UYdcVRQYiIIRu0Rs72v9prw=
=TAC8
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 27 Apr 2023 08:20:34 +0200, Simon Richter <[email protected]>
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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, Apr 27, 2023 at 10:54:58AM +0200, Marc Haber wrote:

On Thu, 27 Apr 2023 08:20:34 +0200, Simon Richter <[email protected]>
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 [email protected] [email protected] [email protected]
PGP key: http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEELuenpRf8EkzxFcNUZR7vsCUn3xMFAmRKUB8ACgkQZR7vsCUn 3xPiIxAAxMIrY4uDk4WiCZ+ae1Cz727oRbtZovp1qqkkHSqDL3GC+pEsog3IEVrr HIkXe7H/NNBWBb8S6DBJbbyToCsTwvn9Gli8O74YWJoMrTdlLpBf0Hfu8+jxe425 H65qIefTO8WbYxmHzCjFlNVkMBiSdA2fIH1HnPpqdqaYKzTFzoYMY1ZqEJPpnGJe Xn2lsuBDpLsdcdCUsOD5rDRrwdBg9TS6l/fvLDcsR/FvdBAleF/t4PcWqarfKQFm 4dEavVMxXc2bR/n9twubfI3kkJ0nRIoOuQbOA0rgFgJI6AWSgRfM78YBuM1u05me r4ScTEAdUNuBTQAAF1SoLBg8ZovdzFk+UkJplSFI6o9DRGoarCSwPnZCCX0Fi5Lw LNmdI4gEn1tKPeTsUtLYDW82nijcNb2NNrMZRFlxnE3ROzYyBVDlEPosKZnhy2EL 6U8A42GXyjnDSnH0Ihdxfu4Wglhi3xpAbUtcAdw3YE+hhFJMLEQG23xn/QBVGGR/ ASHdKlHmHm8HeirzbCka4lBywDkWMfj1kph3bUfkSbX/kvTOyTBr1JTB9wo5HOO/ B40sb9LvOCIIQ1lbt/7JXqi7soIDWqZHYN+IRhqU5FQpUkMwk8MvV4PMIV8Og2hl g0yDPCWa5WTgV7P+T4P+XkrG6CYUX1KxCELwDT4e8ti/9JVG3Ms=
=eIJl
-