Hi Lorenzo and maintainer, On Thu, Apr 08, 2021 at 07:15:30PM +0200, Lorenzo Puliti wrote: > I want one of my packages to divert files from an essential package: I used > code > from examples (with --rename option) online [1] that works fine, but lintian > complains. > Moving essential files can be dangerous, use the --no-rename. > Ok. So I assumend that the same code would work fine, just replacing > '--rename' with > 'no-rename', silly me.. instead it broke my system. > It is true that the manpage states under [ --add/remove] > "The file is currently not renamed, see --rename" > However reading the --rename/--no-rename description I was under the > impression that the > --no-rename was a safer option - overwrite during unpack instead of moving > aside > before the unpack, and that it's safer also when the diversion is removed. > This is not the case, or maybe there is an easy way that i'm not considering > but it's not documented anywere and also serching the code base for examples > [2] > provides no clue.
I too am befuddled by the documentation of 'dpkg-divert --no-rename', as I was looking possibly to use this feature myself. The explanation seems to be accurate as to what it does but it seems pointless with the current behaviour so I wondered whether it was incorrectly documented; apparently it is not. What use is the diversion in the database without any actually diversion activity? I would have thought in the '--no-rename' case we would want to use a copy rather than a rename. And maybe it would be safe to use '--rename' at removal time. That would in fact still leave a race, though, as the file to be installed may not be written in one go. That could be solved by unpacking the new file to a temporary location and then renaming it. That would require cooperation with the install phase though. (Isn't this already a problem for installing essential files anyway? Maybe this already happens - I don't know how the installer works.) Personally I'm inclined to think that in many cases '--rename' would not actually be that unsafe because the failure mode of an operation failing with an error is not the worst possible failure mode. The man page is in any case out of date as it talks about future changes in dpkg-1.20.x but we are already at 1.22.13.
