Hello, On Sat, 22 Apr 2023, Helmut Grohne wrote: > This is looking at it from a performance point of view. Guillem also > raised that this is changing the source of truth from the dpkg database > to the actual filesystem, which Guillem considers wrong and I find that > vaguely agreeable.
smcv already replied to that part. > > > We don't add any new public interface to dpkg, but we also have the > > possibility to remove to /var/lib/dpkg/aliases to force an new scan > > (some sort of "dpkg --refresh-aliases" without an official name). > > Can I rephrase this as your cache invalidation strategy is that any > external entity (such as a maintainer script) introducing aliases should > explicitly invalidate the cache. Yes and no. Sticking to the idea that .deb should be the source of truth, we make the assumptions that external entities should not do that and if they do it, they use the already existing interfaces (either shipping symlinks in a .deb or calling dpkg-maintscript-helper to convert a directory in a symlink or the opposite, depending on the history of said path). > If you put it this way, it is not that different from the > --add-alias/--remove-alias proposal. It is a different interface to > dpkg, but the semantics are roughly the same: > > In both cases, something external to dpkg is responsible for performing > the moves and creating the symbolic links followed by informing dpkg > about the alias (explicitly or implicitly via scanning directories). I don't consider "dpkg-maintscript-helper" as external to dpkg. Quite on the opposite, it's an ugly hack that is part of dpkg so that it can evolve together with dpkg relying on internal implementation details that nobody else can rely on. > Would you agree with me that this is a minor adaption of DEP17? In It is an adaptation of DEP17 that tries to not create a new public interface for users. Whether that change is minor or not, I leave that up to Guillem to decide. My hope is that the restricted scope makes it acceptable to him. > > The proposal I made above is not a real database in the sense that we > > don't record what was shipped by the .deb when we installed the files... > > it's rather the opposite, it analyzes the system to detect possible > > conflicts with dpkg's view of the system. > > I think that Guillem considers this a bad property as he has expressed > in his reply on debian-dpkg, that .debs should be the source of truth. I understood this but at the same time dpkg has supported an exception already, this is only about improving how we detect issues related to that supported exception. Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog <hert...@debian.org> ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋ The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄⠀⠀⠀⠀ Debian Long Term Support: https://deb.li/LTS