Hi! On Thu, 2021-09-30 at 16:21:21 +0200, Andreas Beckmann wrote: > Package: dpkg > Version: 1.20.6 > Severity: grave > Justification: breaks unrelated packages by removing their conffiles > > attached is a small package demonstrating the misbehavior of > remove-on-upgrade which may delete symlink targets. It builds foo.deb > (which has 'remove-on-upgrade /etc/old-conffile') and bar.deb (which > has /etc/old-conffile -> /etc/new-conffile).
Thanks for the reproducer. I'm looking how to best fix this, ideally with a minimal amount of code that might be sensible to add into a stable release. > The actual bug where I encountered this misbehavior is > #994971: OpenCL not working with latest Nvidia driver > and it was an error of debhelper converting rm_conffile to remove-on-upgrade > but dpkg played its part by deleting the symlink target instead of the > symlink itself, but it should rather do nothing (or print a diagnostic) if > the to-be-removed file is not a plain file. Actually I think there's just a problem here with remove-on-upgrade not taking into account ownership from other packages. But the conffile dereferencing is an "expected" behavior (although I think is more of a misfeature than anything else TBH, and I'm not sure it even behaves sanely in all cases, which might require additional tests and fixes), which does the same as with normal purging and unpacking. If there's a symlink then what it points to will be used instead for its contents and for removals etc. > Simplified, the nvidia use case the following: > > Long ago, /etc/conffile was a conffile > That was later removed with rm_conffile > and since then the different co-installable drivers ship > /etc/conffile-$driver_version instead > and a slave alternative exists as /etc/conffile pointing to the corresponding > file of > the activated driver variant. > (The different drivers may require slightly different conffile content.) So given the above, the ownership fix is needed to protect the user, but I don't think it would have helped you anyway, as the alternative is not owned in a way that dpkg knows. So it would consider it a local symlink that can be overwritten. :/ I guess the remove-on-upgrade directive needs a possibly optional version restriction like dpkg-maintscript-helper. :/ Thanks, Guillem
