On Mon, 2024-10-21 at 00:49 +0200, наб wrote: > On Sun, Oct 20, 2024 at 11:39:36PM +0200, Ben Hutchings wrote: > > On Sun, 2024-10-20 at 20:03 +0200, наб wrote: > > > I'd like to use an epoch so I'm asking for consensus per policy 5.6.12. > > > > > > As part of the Salvage Team's trixie view-os removal plan ‒ > > > RM: umview -- RoQA; obsolete, low popcon > > > #1085454 > > > RM: fuse-umfuse-ext2 -- RoQA; dead upstream, low popcon > > > #1085457 > > > + replace with https://github.com/alperakcan/fuse-ext2 > > > RM: umview-mod-umfusefat [amd64 i386 ppc64] -- RoQA; view-os removed > > > ITS #1085458 (2024-11-09); > > > https://github.com/virtualsquare/fusefatfs/pull/2 > > > RM: fuse-umfuse-iso9660 -- RoQA; dead upstream, duplicates fuseiso > > > #1085456 > > > + implement "fuseiso -o fuseopt -o fuseopt iso mtpt" in fuseiso > > > #1083034 > > > (currently only accepts "fuseiso iso mtpt -o fuseopt -o fuseopt") > > > have that provide a transitional package > > > (sge@ contacted thus) > > > ‒ fuseext2 is to be provided by https://github.com/alperakcan/fuse-ext2 > > > instead of src:fuse-umfuse-ext2. > > > > > > The current version of src:fuse-umfuse-ext2 in sid is 0.4-1.5, > > > and the current version of https://github.com/alperakcan/fuse-ext2 is > > > 0.0.11, > > > so src:fuse-ext2 would need to be version 1:0.0.11-1 to update right. > > > > > > Thoughts? > > > > Given that fuse-ext2's README says "please do not mount your > > filesystems with write support unless you have nothing to lose", is it > > really suitable to replace the current implementation? > The current implementation's README also says this, so I'd say so, yeah > (the manuals for both clearly indicate that R/W mounts are experimental). > > The similarity was too good to be accidental, and seemingly, per > > https://sourceforge.net/p/view-os/code/HEAD/tree/trunk/fuse-modules/fuse-umfuse-ext2/ > fuse-umfuse-ext2 is actually just a fork of fuse-ext2:
OK, so it sounds like this probably won't be a regression. [...] > > Perhaps it would be better not to provide any replacement until fuse- > > ext2 is more mature - at which point its version may have increased > > such that an epoch is not necessary. > Given the above, this is looking less like a replacement > and more like a version bump with upstream changing versioning schemes? > Either way, I feel like this resolves the question of implementation maturity. > > (I also don't fore-see fuse-ext2 version ever growing past 0.4.0, > seeing as in the past decade it grew by 0.0.5.) > > Thoughts? Given the relationship between the two projects, it might be worth asking upstream to bump the version number so it's more obviously newer than the forked versions. But if they won't do that, adding the epoch seems pretty reasonable. Ben. -- Ben Hutchings It's easier to fight for one's principles than to live up to them.
signature.asc
Description: This is a digitally signed message part
