On Wed, Oct 23, 2024 at 10:53:29PM -0400, Theodore Ts'o wrote: > On Tue, Oct 22, 2024 at 04:56:05PM +0200, наб wrote: > > ...but now that I look at this there's fuse2fs, > > which is naturally better than some third-party implementation. > > > > The interface is a little different > > (the default is -o rw instead of -s -o ro,allow_other,default_permissions) > > so this can be turned into somehing like > > src:e2fsprogs -> fuseext2 (transitional package) Depends: fuse2fs > > + adding the current fuseext2 interface with a wrapper to fuse2fs > > and dropping the transitional package in forky and the wrapper... never? > > in forky? forky+1? > > > > (Or just RM fuseext2 and let users figure this out on their own but > > that seems awfully anti-user.) > > > > The epoch is avoided because e2fsprogs is 1.47.1. > I suppose another, simpler approach might be to have the fuse2fs > package ship the fuse-ext2 wrapper script, and then we can just have > the debian fuse2fs replace/conflits with fuseext2. I'm certainly OK > with doing this if someone wants to send me a patch. Thanks, this is most likely the best approach, then. I've implemented this but can't test it fully because https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git is missing an up-to-date pristine-tar (it's at 1.47.0 so it looks like you just forgot to push?). Draft @ https://git.sr.ht/~nabijaczleweli/e2fsprogs, will post & file this in the usual manner once I manage to build and test. > I'll note that e2fsprogs's fuse2fs supports 64-bit filesystems, Posix > ACL's, and has thread supports enabled, in contrast to fuse-ext2 which > does not. Yeah, I expected as much. My summary of the diff was from the perspective of the user-facing interface only (it'd certainly be nice to just solve this with d/fuse2fs.links, but the default changing from R/O to R/W is unacceptable IMO). Best,
Attachment:
signature.asc
Description: PGP signature