Hi!
On Wed, 2023-06-21 at 23:24:53 +0900, Simon Richter wrote:
> On 6/21/23 20:33, Guillem Jover wrote:
> > I don't think we disagree (?), I probably didn't express myself clearly.
> > The fact that no package ships those symlinks *is* and *has* been a
> > problem, and what I've been saying all along, this will be the only
> > correct way to let dpkg know whether there will be aliasing in play.
>
> I've looked into building a dpkg-alias tool that would work similar to
> dpkg-divert, and currently that looks like it might be a viable solution.
Hmm, I get the impression the bulk of the mail this is replying to
(and other previous ones), got ignored here.
> The package would need to unregister on upgrade in the postrm though, but
> that is standard for removed diversions.
>
> - dpkg-query returns the package name if any aliased name matches
>
> There should also be a flag whether to report the file name from the
> data.tar as well, defaulting to "no", because that's what scripts expect.
That completely breaks the interface. This is one of the things that
this change-at-a-distance breaks. The packages expect to be able to
find their own files under their shipped names, not something the
system might have done under their feet. So this new behavior can
never be the default.
> > But given these mentioned constraints
> > it cannot be made to support (as in accept) unpacking files inside
> > aliased directories (it should be able to unpack the symlinks creating
> > those aliased directories though!).
>
> I think that can be done. I have already successfully made it report a
> conflict between /bin/testfile and /usr/bin/testfile, with a meaningful
> error message, and runtime overhead isn't too bad -- a factor of
> log_{262144} 2 on the lookup time for a single path, but inserts got a bit
> more expensive because these now have prefix comparisons on the path. The
> latter could probably be improved with another hash on the first N bytes of
> the path.
I think this comment does not take into account the "mentioned
constraints". A directory cannot be replaced atomically, even less so
if it is non-empty. If it is empty and only owned this package, then
it is still non-atomic, and replacing its file-type seems like
safe-ish thing to do, as it does not suddenly disappear entire
hierarchies that would stop being accessible through the old pathname.
But moving entire hierarchies is simply not possible to do in an
atomic and crash resistant way. This is one of the reasons dpkg-divert
refuses to operate on directories.
This also seems to ignore for example the ordering issue I mentioned
before.
I have no doubt that the "db aliasing" could be "done", although that
also breaks a bunch of interfaces, but that's not the point, the
problem comes from its consequences on unpacking and on the disk, and
on having to sync the world views for these with the contents in the
db on an ongoing basis.
> I'd like to see a mechanism that ensures that dpkg understands those control
> files, though -- like a "critical" flag.
I don't think this is possible in a quick or non-nasty way (currently),
given that such mechanism does not exist today, and we'd need to wait a
release cycle to be able to use it anyway. In general things get
introduced into dpkg, and then depending on the interface they can be
used right away or one needs to wait until it can be used; if it's an
independent tool that does not require any support from the running dpkg
then that just requires dependencies, if it is part of dpkg then you
need to wait, or if it's an optional feature you might be able to use
«dpkg --assert-*» to check for availability, or just to bail out if
it's a hard requirement.
(Using a different .deb member that comes before the expected ones
would be an option, which seems like the nasty but only existing
mechanism for what this would involve, given the requirement to
update all .deb consumers, and because it would be taking over the
role of the control.tar member.)
But for the future, perhaps it's worth considering, yes.
> I suspect that for trixie, this will have to be an archive side check that
> any package using one of the declarative interfaces depends on an
> appropriate version of dpkg, and/or its use disallowed until trixie+1 for
> the convenience of backporters.
If we can manage to move files to their canonical locations, then the
bulk of the aliasing disappears, and then as I've mentioned before
then dpkg only needs to eventually become aliasing aware (in the fsys
db sense from the fsys metadata) and simply get to an eventual point
where it can (once it has a complete fsys metadata view) reject any
potential attempt to perform a similar migration that would otherwise
be unsafe and non-atomic. Any such migration would require to first
move contents into their destination and then switch the dir to a
symlink (which will be possible automatically once dpkg has the fsys
metadata and can then replace the matching logic in
dpkg-maintscript-helper), like we have been doing for /usr/share/doc/
for ages for example.
Thanks,
Guillem
