Hi! On Thu, 2024-06-20 at 23:27:07 +0000, Thorsten Glaser wrote: > Dixi quod… > >Or, better yet, absence of that entry in the ustar (possibly > >combined with a Pre-Depends). It’s ridiculous that every pak‐ > >kage ships all those directory entries anyway. That avoids
These directories are included because the package should be self-contained and ship all required parent directories, otherwise dpkg would fail to unpack as you mentioned (even though there's generally the Essential set in play), and so that the directory "ref-counting" (as a shared resource) works and the last package shipping it that gets removed/purged (regardless of the order) can properly remove all owned entries. Also for «dpkg -S»'s sake. > Hmh, lintian warns, and dpkg needs the directories present if > not in the .deb, but most likely we c̲a̲n̲ skip top-level dirs. > I’ll experiment later when less headaches. It looks like you went in this direction for the packages in Debian. But I'd ask you to please stop doing that, as I consider this to also be breaking dpkg assumptions. And as part of the filesystem metadata tracking support that should be coming to dpkg, I was already thinking some time ago about checking for this specific case as part of its integrity checks (detecting and erroring out on missing parent directories), in addition to refusing to install files inside a symlink aliasing to a directory to avoid all aliasing problems (which would make this package uninstallable). Of course this will not be enforceable on merged systems until the current transition has been finished and there are no file type conflicts in the archive (so at least until after trixie). When it comes to the mention of the canonical path (which you disagreed with), I think in general this has been understood as the canonical location in both the filesystem (as in where the file ends up physically) *and* the dpkg metadata, so that they both match. I agree that this is *not* the canonical path for the _interface_, and that is still /bin/<something>, and personally I consider it rather important that for pathnames that are part of a specified interface (like shells, ld.so, etc), these get used by callers as such (or no absolute names be used, and instead relative ones if possible via PATH-like mechanisms). In the future my plan is to add a special dpkg filesystem metadata type to explicitly describe this kind of (optionally) aliased interface so that if the alias is already present on the system (as represented by the parent object being a symlink known to dpkg in its metadata tracking) it will just be shown as an additional pathname in dpkg output and matched on searches, and if there's no such aliasing then dpkg will create the required symlink (for the aliased object itself, not its parent). So the data.tar would contain /usr/bin/<something>, the package would declare /bin/<something> as such optionally aliased object, and then «dpkg -S /bin/<something>» would work regardless of the filesystem layout, and the object would also always be found on disk either via the aliased directory on merged systems, or via a symlink from /bin/<something> to /usr/bin/<something> that dpkg creates during unpack on non-merged systems. So that interface will always be guaranteed, and the unpack will be safe. Thanks, Guillem
