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@kiyuko.org>
Resistance is futile, you will be garbage collected.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEO48t9niVypx3EjLf954fxUKFg6wFAmfXOQsACgkQ954fxUKF g6wx1hAAqNsvctbh6WdiRg5T+SRYEIQiH1IhsqKySfM59Km3fHTZpbBy4kV5SsN6 3eOAV689WO1lnxi6bQQm0uc1Bf6xRCQn/InTnhAVuTHsXSquQIieynKrAgiDOR3G Ricjy9ihZAzx3MHr/P3rIEdWF5gIUtZ//zIY8A0M602g9Ix66ZHBrmsna4kMvLRi KI4XpzcM7uGv0ANwethro1ieY1pjyYgkX6w/hQQfoQzPs2b1DJgqVem3nHwzZH0g 7sLxICYm233bfIRWStZ59G+d9VdBdY1kXpMcIl6nrLqhHo0MQalOIV72UwR2St4K Zj6B6xNqCOws9E0kK/+66uJr//A7hfxhFh3DKswtNo1vTq4JBSmz1uMDOx9b8DVW nKsOu68pnW6AYyVc8pE2k8W+glJhFN3phRgFXRo7RssoanPKmwro3Ybgz1V7VGlN TODBKDpTUgGd70CX8HUFub6C0kKOjPhwu4/zZZjp6BI1xFTKkez7wiqGks8dP6Wy mhqhqZp5jNSL3d/PhPVVWYgDqa1sYr4yXH2Mr8zEKaDNCDn6XLIfW17Ai/2iVt0k ubd+40TA8Cxatu/oDchChH4ZsLVv8fJ0mIe5SXXFi9gqMwKKb3ssrDZ1nmQwDQvq g0EQiP1xhhvudzKtWRU+6zAF1at29pr8Lv9YhfQzvzblbaAXlso=
=D8aL
-----END PGP SIGNATURE-----
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)