* Simon Richter <sjr@debian.org> [2021-08-26 14:51]:
It makes a lot more sense to have a dpkg-internal tool that can investigate the differences between the file system and the dpkg database, resolve conflicts (possibly in an interactive process when required by a corner case like the one I mentioned earlier -- luckily, these should be really rare) and then leave a consistent state again that allows package maintainers to use all dpkg features again after the bookworm release.
Agreed. Having yet another tool messing with dpkg "behind its back" will only exacerbate the problems we're trying to solve. Also, I wouldn't say it is the *only* possible way to move forward, but it is *a* possible way. I am also still trying to understand Guillem position and his objections better. This proposal addresses one half on Guillem's objections by makingdpkg's point of view consistent with the actual filesystem reality.
However, Guillem also seems to think that dpkg can manage file symlinks in a real directory better than an directory symlinks in /, which is why he proposed symlink farms in the first place. Assuming dpkg implements the proposed canonicalization, is there a scenario where the aliased dirs break, but would not break with a symlink farm? My apologies if this has been answered already. Just point me to the relevant emails/wiki pages then. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭────────────────────────────────────────────────────╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄⠀⠀⠀⠀ ╰────────────────────────────────────────────────────╯
Attachment:
signature.asc
Description: PGP signature