Package: fuse,fuse3,ntfs-3g
X-Debbugs-CC: Laszlo Boszormenyi (GCS) <g...@debian.org>, Helmut Grohne
<helm...@debian.org>
Hello Laszlo!
fuse, fuse3, and ntfs-3g use dpkg-statoverride on aliased paths in
/bin: /bin/fusermount, /bin/fusermount3.
They do so in their postinst scripts, only checking if a
statoverride exists. If not, they run chmod on some programs.
The postinst does not add a statoverride.
As you know, these paths need to become canonicalized to /usr/{...}.
When this happens, the old dpkg-statoverride entries stop working.
Now my question: do you think it is worth migrating any such
dpkg-statoverride automatically?
If not, how should users/admins who previously created an override
be informed about this problem? Some suggestions might be:
- NEWS.Debian entry
- trixie Release Notes
What do you think?
I've started working on UsrMerge patches for fuse and fuse3. Those
patches would need to take into account the question above, and also
the file loss problem between fuse and fuse3.
Additional context: the three packages are the only packages in this
"problem space". One other package uses dpkg-statoverride on an
aliased path, but it also creates the override - what we decide here
might influence that package, but probably not.
I hope to hearing from you about this soon,
Chris
