Patrice Duroux wrote:

By the time on my Sid system, there is an accumulation of:

$ systemctl list-units --all | grep '●'

probably it is best to use
$ systemctl list-units --all --state=not-found

I try to understand where is the problem

For example
$ LANG=C dpkg -l podman
dpkg-query: no packages found matching podman

$ systemctl list-units --all podman.service
UNIT LOAD ACTIVE SUB DESCRIPTION
● podman.service not-found inactive dead podman.service
[...]

but there is not podman.service file anywhere
there is not a dependency in any systemd service

but:
$ systemd-analyze dump podman

Unit podman.service:

Description: podman.service
Instance: n/a
Unit Load State: not-found
Unit Active State: inactive
State Change Timestamp: Sun 2024-04-07 11:41:49 CEST
Inactive Exit Timestamp: n/a
Active Enter Timestamp: n/a
Active Exit Timestamp: n/a
Inactive Enter Timestamp: n/a
May GC: yes
Need Daemon Reload: no
Transient: no
Perpetual: no
Garbage Collection Mode: inactive
Slice: n/a
CGroup: n/a
CGroup realized: no
WantedBy: multi-user.target (destination-file)
ReferencedBy: multi-user.target (destination-file)

so I found a dead symlink
$ ls -l /etc/systemd/system/multi-user.target.wants/podman.service
lrwxrwxrwx 1 root root 34 1 ago 2020 /etc/systemd/system/multi-user.target.wants/podman.service -> /lib/systemd/system/podman.service

$ LANG=C ls -l /lib/systemd/system/podman.service
ls: cannot access '/lib/systemd/system/podman.service': No such file or directory

It seem that removing podman package don't remove the symlink

Ciao
Davide

--
La mia privacy non è affar tuo
https://noyb.eu/it
- You do not have my permission to use this email to train an AI -
If you use this to train your AI than you accept to distribute under AGPL license >= 3.0 all the model trained, all the source you have used to
training your model and all the source of the program that use that model

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

On Sat, Apr 13, 2024 at 08:30:35PM +0200, Patrice Duroux wrote:

Ok so this is probably due to the version of the DHs used when generating the postrm script during packaging.

How?

On my system, the diversity is quite large regarding all the installed packages
and the dh_installsystemd:

$ grep -ho 'dh_installsystemd/.\+' /var/lib/dpkg/info/*.postrm | cut -d '/' -f 2 | sort -u
13.10
13.11.1
13.11.4
13.11.6
13.11.7
13.11.8
13.11.9
13.13
13.14.1
13.15.2
13.15.3

Does this lead to any problems?

For a given (old)stable release, is this more homogeneous?

No. Packages are not rebuilt for each release.

Under control by any QA tool?

No, as it's not considered a problem.

--
WBR, wRAR

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

iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmYa194tFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh mOcP/iXUoAxkbZno6YEEu9kCcUnNCkVUtWzROk2LLezd5t6VeGZtbt9j6/jnWkvv GPKmWX2nRlrdvOWCI/8YJ7TMgwKlU2vh9djhhBnW+NK4XFAiN8fAlOK1byyZpxWF ObG7nJOS82eeloex75e4tOS1XF2msK3ujabeR731M3NwN6K0CHyNtscbmPBIVgn2 RFPLQ2p1Z+Ereu1ib6FWtUPQE00XHXtA8kGnSUeMWHKLPga4GikE/RJXo7Xjsvb9 8wbNYIUs1RymojitqdDBZoKCn9DVmVT15UAY1v4YqIz43nj1OT+lRJ8tc+yqIaWk xSdOWI+yEqjbFarafBd5XDmX452S8XRbMWRYOgXyYisfE0fSuT+g4aW7hHuyaV81 XH1ThOOpFM4QVLJEAUq4935oVk0NnbK8zQCva/e4Rp7aCN7rt6T3Fs4/rQS4QTO3 +m6WYSO5Zs2ica9ceSSKL3YKtlicqq4G6Jl0/pdjqQqXGflpHSUsIAVMD8HecDs1 BRmcM+uvhXaYwcsH7UNX5kRrvGZZtBjRTVBE3MxOuLCwoFirB/si1osZ0qOrCc+L sGyvHeS8ZPv2yXq6BvvC7ah2jQvilsydvOuyTskITiu4K8ZomWJ2b+mcWvQBThAi otNmJsxCmCfbvu3HAcfA+sfKwj340kGMHUm4Q1UVWB/rUNWn
=XY0B
-----END PGP SIGNATURE-----

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