/etc/init.d/virtlogd 8b6942d513cc5b6ec130556952577850 obsolete
 /etc/init.d/libvirtd 6615f190c140a2e0aeecfc082716d026 obsolete
 /etc/init.d/libvirt-guests 7efd4986a88c0f0bd1c5ae9826802b3f obsolete

Those files are not properly cleaned up on upgrades.

Guess the reason might be that the version used with dpkg-maintscript-
helper rm_conffile could be wrong.

(AFAIU, the version that needs to be specified for that is NOT
the version where the conffile was dropped, but rather "the
latest version of the package whose upgrade should trigger
the operation"

Quoting the manpage:
           For example, for a conffile removed in version 2.0-1 of a package,
           prior-version should be set to 2.0-1~. This will cause the conffile
           to be removed even if the user rebuilt the previous version 1.0-1
           as 1.0-1local1. Or a package switching a path from a symlink
           (shipped in version 1.0-1) to a directory (shipped in version
           2.0-1), but only performing the actual switch in the maintainer
           scripts in version 3.0-1, should set prior-version to 3.0-1~.


It seems to rm_conffile was added with d88536d which is 5.6.0-4 while
rm_conffile is invoked with 5.6.0-3\~



Cheers,
Chris.

So, this affected upgrades from buster (libvirt 5.0.0) to bullseye
(libvirt 7.0.0).

We're now about to release bookworm (libvirt 9.0.0) and the
rm_conffile snippet is not even present in the package anymore.

I think at this point we can assume that most people who have hit the
issue on upgrade will have cleaned things up manually by now, so I'd
be inclined to close the bug and move on.

Any objections?

Well not a strong objection from my side, but I think typically most
people will rather simply not even notice that they have leftover
files, so they'll stay there forever unless cleaned up properly.

Cheers,
Chris.

I understand that, and ideally I would love to keep things tidy.
However, I'm afraid we might have missed our chance.

At this point, nobody is going to be upgrading from 5.6.0-3, but from
a more recent version of libvirt-daemon-system where the conffiles in
question are already not considered part of the package.

Note that these conffiles are not actually gone, they've just been
migrated to the libvirt-daemon-system-sysv. So we can't simply delete
them from the system without a version check, otherwise we'd break
all sysvinit users.

I can't think of a simple, reliable way to handle cleaning up under
our current circumstances.

Another thing to keep in mind is that we're likely going to move
these conffiles *back* for trixie[1], or possibly move them to some
newly-introduced packages. That's going to be tricky (ah!) already,
and I'd rather not complicate things further by layering that work on
top of some late cleanup code.


[1] https://salsa.debian.org/libvirt-team/libvirt/-/merge_requests/169

As said in my message #10 in this bug,... I don't think it's necessary
that the conffiles are cleaned up exactly the version after they have
been dropped.

AFAIU, you'd simply replace the rm_conffile with a version right before
that of the next upload.

E.g. currently we have 9.0.0-3 in sid.

If your next upload were 9.0.0-4, you'd have to use 9.0.0-4~ (note the
tilde) in rm_conffile.


At least that's how I understand the manpage.
knowledgable than myself and has done such moves previously in systemd
packages... so he may tell you way better about the proper way to
handle that.

But blindly I'd assume, one would do something like:
- cp -a the file that is still considered a conffile for
  libvirt-daemon-system (despite being actually considered as part of
  libvirt-daemon-system-sysv) to some safe mktemp location
- do the rm_conffile <priorversion> libvirt-daemon-system
- mv the file back to the old location

Then it should no longer be a conffile for libvirt-daemon-system,
should still be identical (with any possible set
XATTRs/ACLs/whatsoever) and you could from then on consider it as
belonging to libvirt-daemon-system-sysv.


The only thing I'm not sure about:
You still want the files to be conffiles (just in another package)...
with rm_conffile you can specify the package,... not sure if dpkg is
smart enough to keep the file as is (and you could just skip the whole
copying stuff) if it sees that the file is a conffile for another
package.

@Michael? What's the expert saying? :-)


Cheers,
Chris.

It's a bit more complicated than that, because the logic in
dpkg-maintscript-helper looks at things such as whether the conffile
is still considered part of the original package and is marked as an
obsolete conffile... With multiple Debian release having happened in
the meantime, I'm not sure what dpkg will report for these conffiles
on systemd and sysvinit hosts.

Transferring conffiles between packages is trickier than dropping
conffiles. We've done so in libvirt in the past, and it required some
custom logic. In this case, we'd have to be even more careful.


Anyway, I wouldn't do anything about these files right now, knowing
that their state is most likely going to change again during the
trixie cycle. When I start working on that, I'll try to keep in mind
this half-completed migration and handle it in the best possible way.

Coming back to this bug after a long, long time because I recently
had to dig into the topic again due to #1094583.

If you check out the solution I've proposed for that bug, you'll
notice that it involves potentially leaving even more obsolete
conffiles around. I don't love that, obviously, but it genuinely
feels like the lesser evil, all things considered. I won't repeat all
the relevant information here, just go read that bug report.

Note that adding rm_conffile calls is *not a good idea*, despite
intuitively looking like the correct thing to do. Our primary goal is
to reliably transfer ownership of conffiles between packages, and the
way dpkg-maintscript-helper implements this operation actively gets
in the way.

For example, imagine that you are moving ${conffile} from srcpkg to
dstpkg. If the file contains local modifications, srcpkg's preinst
will rename it to ${conffile}.dpkg-backup; afterwards, when dstpkg is
unpacked, dpkg will not find the original version of ${conffile} and
will thus just install the default version shipped with the package,
causing the local customizations to be lost. If the packages are
unpacked in the opposite order that won't be a problem, but the exact
order of installation is not something that we can really rely on, so
using rm_conffile is effectively out of the question.

Based on all the above, I'm leaning towards simply closing this bug.
I'll give you folks some time to weigh in before doing that though :)

It's correct that there is no native support in
dpkg(-maintscript-helper) to transfer ownership of conffiles properly
from one package to another.

It is doable though with some contortions, see e.g.
https://salsa.debian.org/systemd-team/systemd/-/commit/d6483013d5779d4d465a1e174e44a754b941d0e6
where
/etc/dhcp/dhclient-exit-hooks.d/timesyncd and
/etc/systemd/timesyncd.conf were moved from systemd into a newly split
off package named systemd-timesyncd.


Michael

Yes, I'm aware of that. libvirt currently does something similar,
though not exactly identical.

The changes I'm proposing in

https://salsa.debian.org/libvirt-team/libvirt/-/merge_requests/256

do away with all that logic in favor of using dpkg's built-in
handling. It's a little less polished, specifically because of
conffiles remaining around as obsolete for the old package in certain
scenarios, but the gains in terms of simplicity and reliability IMO
far outweigh those drawbacks.