[Pkg-libvirt-maintainers] Bug#953997: obsolete conffiles after upgrade

[Andrea Bolognani]

On Mon, May 15, 2023 at 10:56:20PM +0200, Andrea Bolognani wrote:
> On Sat, May 13, 2023 at 06:09:22PM +0200, Christoph Anton Mitterer wrote:
> > On Sat, 2023-05-13 at 12:09 +0200, Andrea Bolognani wrote:
> > 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.
> 
> 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.
> 
> > 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.
> 
> 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 :)

-- 
Andrea Bolognani <eof at kiyuko.org>
Resistance is futile, you will be garbage collected.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-libvirt-maintainers/attachments/20250316/c88b78e6/attachment.sig>