Dear Mentors,

in runit, services are defined as directories with files inside and
I'm not sure what exactly can or can't be done when a package has to
purge a service:

if the service is below /etc, files provided by the package can
be removed even if modified, but the directory can't be removed
if there are extra files inside. Correct?

if the service is below /usr (or /var or /run) instead the directory
can be removed entirely, disregarding extra files ?

what if the service is in /home, like in user-services ? maybe symlinks
and empty directories (created by the package) can be removed, but not
files?

Thanks,
Lorenzo

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

On Sun, Jun 30, 2024 at 10:39:06AM +0200, lorenzo wrote:

Dear Mentors,

in runit, services are defined as directories with files inside and
I'm not sure what exactly can or can't be done when a package has to
purge a service:

if the service is below /etc, files provided by the package can
be removed even if modified,

Normally no.

but the directory can't be removed if there are extra files inside.
Correct?

Just leave this to dpkg.
Unless by "files provided by the package" you don't mean files (and directories) actually shipped inside the package.

if the service is below /usr (or /var or /run)

"/usr (or /var or /run)" sounds wrong, those are very different cases.

instead the directory can be removed entirely, disregarding extra files ?

This sounds very wrong in general.

what if the service is in /home, like in user-services ? maybe symlinks
and empty directories (created by the package) can be removed, but not
files?

Maintainer scripts must not touch /home.

--
WBR, wRAR

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

iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmaBKHwtFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh ElkQAKc7KZhguMhKjotoDsWYFUMPvdWt5WqXGpSD3KYkhKR7ALkNEMKiatukVqad SASPEUKofP2gX9wCTKPUUC3j7xMzn8cq7G/42BnZS3I8sRCS/PdJWvJcIyU0IVua Ahj3mWHfy1Fthx4qpc0xq/irJh5IGIzCcfsR8mK1bOz2JS1mC+PaOxSFikSKPclI Rpwi0bd0l2bNk5hpvcu6zUjxk/kaRsWYSuBdZEhLrx9uUHzIicf4xTRr7lKw5LhY ii7FRRE45ISsrLJHXtdqQwco/JK2RURvdlpNpDoQB0ISp/LPHLy7UTg3m8wlwMNw WA32jxu0CrNf8jxTQ3U+tcWgfKy19Qf3EadIAMoh4edQhoAOU/BJgdoFp1iN6xCr G/4SZPvZT1rnhy7tKV4hl4a58ZizOgZPRWxw71E8nw8Wq3SE+Cqr5B2Vk9SN5Akn 5qLnx2QrwDWCLBPruFnJr5qjpj3ag33buzSt7y+bz0DQc23Zu2stWpDHzOAygucI HNszc+H2nFbWBBbNPbdNx31DdH9USp6zIXYFGKN2kMmle6I8NU7BkXrM4mqTANVY Khj/WYCUuD9k3VLGFOSXsxbowtlGo2epwSfAUbZVJG8NqYH7XjajeEQLE6bAUo0C yx/Jz3AItYaGE+Qr5HUfgqxbvfwfcB+n7cCNw4ZoBbpV3B1b
=1ygO
-----END PGP SIGNATURE-----

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

On Sun, 30 Jun 2024 14:42:20 +0500
Andrey Rakhmatullin <wrar@debian.org> wrote:

if the service is below /etc, files provided by the package can
be removed even if modified,

Normally no.

but the directory can't be removed if there are extra files inside. Correct?

Just leave this to dpkg.
Unless by "files provided by the package" you don't mean files (and directories) actually shipped inside the package.

Yes that's the case, there are files, symlinks and subdirectories
created during runtime, and I need to clean up on purge.
I'm taking what dpkg does as a reference; also policy 10.7.3 and 6.8
says something about purge, and it seems that what I described above
for /etc is correct, isn't it?
However I can't find anything for files that are not below /etc, except
that log files should be deleted on purge.

if the service is below /usr (or /var or /run)

"/usr (or /var or /run)" sounds wrong, those are very different cases.

few runtime files are created below /run (ancient version of the
package used /var), think of something like a PIDfile or a socket, but
inside a directory. what should I do on purge?

instead the directory can be removed entirely, disregarding extra
files ?

This sounds very wrong in general.

Can I set a runit policy that says that, under a very specific
directory, it will happen?
Should I bring this to debian-devel, debian-policy or there is another
more appropriate list?

what if the service is in /home, like in user-services ? maybe
symlinks and empty directories (created by the package) can be
removed, but not files?

Maintainer scripts must not touch /home.

this is problematic too, as, for example, it imply that the package can
not enable or disable a user-service by default; for example, a desktop environment with pipewire would come up with no sound by default, and
the user will have to manually stop/disable the pipewire service on
pipewire removal

Lorenzo

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

On Sun, Jun 30, 2024 at 08:08:58PM +0200, lorenzo wrote:

if the service is below /etc, files provided by the package can
be removed even if modified,

Normally no.

but the directory can't be removed if there are extra files inside. Correct?

Just leave this to dpkg.
Unless by "files provided by the package" you don't mean files (and directories) actually shipped inside the package.

Yes that's the case, there are files, symlinks and subdirectories
created during runtime, and I need to clean up on purge.
I'm taking what dpkg does as a reference; also policy 10.7.3 and 6.8
says something about purge, and it seems that what I described above
for /etc is correct, isn't it?

Yes, it's fine to delete configuration files on purge.

if the service is below /usr (or /var or /run)

"/usr (or /var or /run)" sounds wrong, those are very different cases.

few runtime files are created below /run (ancient version of the
package used /var), think of something like a PIDfile or a socket, but
inside a directory. what should I do on purge?

Those files should be created when a process starts and removed when it
ends so it's not a job of a maintainer script to clean them. Even if for
some reason they aren't cleaned properly after the process ended, they
will be removed on the next reboot.

instead the directory can be removed entirely, disregarding extra
files ?

This sounds very wrong in general.

Can I set a runit policy that says that, under a very specific
directory, it will happen?

I know nothing about runit or its policies.

Should I bring this to debian-devel, debian-policy or there is another
more appropriate list?

Not sure what is the actual question you want to discuss there. If it's runit-specific a proper place is likely also runit-specific.

what if the service is in /home, like in user-services ? maybe
symlinks and empty directories (created by the package) can be
removed, but not files?

Maintainer scripts must not touch /home.

this is problematic too, as, for example, it imply that the package can
not enable or disable a user-service by default; for example, a desktop environment with pipewire would come up with no sound by default, and
the user will have to manually stop/disable the pipewire service on
pipewire removal

Is this some runit-specific problem too? It's obviously not a problem in
the default installation with systemd and /usr/lib/systemd/user/pipewire.socket.

--
WBR, wRAR

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

iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmaBtH0tFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh FQ4P/A57Fe4PF+B78lDCJkHCuULUv4TgniZpezq2hA6j4lI8c3A4PY9X16Kw0eoR dgB9b6tu/NoeYxzqZcHHmJMk/h1onRWInLliMckODBcOM4z7KtuYDFCN/eAiYmQw yQ0fqhKlHedYZ/3YlVim+2cmxqPWJRxX2JqebCPa/t0tkw5kEQdWal7BUY2d7s/u LlY8pKwPKL0YXP+AtEbqlTNNpV40WzdZLC869lbJF91HJ2PoJt/TI/9e90Qa7y/j VpFTFyy8CexIHW0gPNwPn16n91XOSz/r14K6tT4StYDZ7NVB+69T1wr5prW/GlgL ISVJSIFdYuauHpgeZJGanLmg2Nf/lbNsZVVjl3v8KNlcIiMVFgqslVRZtiof/gMu Bpb+LK0XR0sKKyIQIUYyx9tc+W64pOPUvTOAA47YSjBADb1MvE0vo5m4+XhWLkfu Zg6GcBCC56fkHEZ1YmruDHB1PGiuKxjsBYZB5N1T0feMZUkbM72m9kt2raSaKmfu Sq5ri0u0IcPUkh7Q2Fl5eRd7dH7B6/A5ANb39q8qTJpsTRJ54EyvvEraUXuUI5ZE YZDi44xkFzNVHy9ICCWXl7PqKlRF37D2m6Kuv3ecfmDOvP46k9Evk27a5bpiVTb+ FWrHryJoCSf1fC8Pn10DzPs0yWNc/UU3aF2TirALo7Xr62sL
=I7JL
-----END PGP SIGNATURE-----

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

On Mon, 1 Jul 2024 00:39:45 +0500
Andrey Rakhmatullin <wrar@debian.org> wrote:

Not sure what is the actual question you want to discuss there. If
it's runit-specific a proper place is likely also runit-specific.

ok

[...]

Is this some runit-specific problem too? It's obviously not a problem
in the default installation with systemd and /usr/lib/systemd/user/pipewire.socket.

yes it's specific to integrating runit in Debian, sorry for not being
clear about that.

Thanks,
Lorenzo

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