Re: DEP 17: Improve support for directory aliasing in dpkg
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 <hertzog@debian.org>
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋ The Debian Handbook: https://debian-handbook.info/get/
⠈⠳⣄⠀⠀⠀⠀ Debian Long Term Support: https://deb.li/LTS
Reply to: