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: ------------------------------------------------------------------------ r1119 | rd235 | 2013-09-01 16:01:35 +0200 (Sun, 01 Sep 2013) | 2 lines Autotools bugfix (new versions require AM_PROG_CC_C_O and AM_PROG_AR, tnx phra) ------------------------------------------------------------------------ r1077 | garden | 2012-06-24 16:30:45 +0200 (Sun, 24 Jun 2012) | 1 line Add dist-bzip2 to automake options. ------------------------------------------------------------------------ r1076 | garden | 2012-06-24 16:19:35 +0200 (Sun, 24 Jun 2012) | 1 line Set version to 0.4 instead of 0.4.0. ------------------------------------------------------------------------ r1069 | rd235 | 2012-06-24 14:40:01 +0200 (Sun, 24 Jun 2012) | 2 lines fuse-ext2: man page added. version updated. ------------------------------------------------------------------------ r1067 | rd235 | 2012-05-13 11:54:35 +0200 (Sun, 13 May 2012) | 3 lines fuse-umfuse-ext2 is a fork of fuse-ext2 for linux only. r1067 has a changelog that matches https://github.com/alperakcan/fuse-ext2/commit/789d5ee3dd414ef5b832dc1218c9fe86e1bebb48 (untagged, 22 Jun 2009, "0.0.6.0"), except view-os calls it 0.3.8 in configure.ac for an unstated reason. None of the later revisions meaningfully change much of anything, but r1067 itself carries quite a large diff against 789d5ee. A diff that to a large extent seems to correspond to https://github.com/alperakcan/fuse-ext2/commit/792239a4b5ddb6bd5206f444181ef415152fb6a2 (September 2009, so the timeline matches? kinda? not sure what the 2012 is doing here given that fuse-ext2 imports a derivative of the manual from r1069 in another Sep 2009 commit). The next entry in the fuse-ext2 changelog is 151781ff (Alper Akcan 2009-09-06 21:04:38 +0000 54) - view-os compatibility (see wiki.virtualsquare.org, umfuse) and fuse-ext2 still builds the view-os module, and view-os (or VUOS or whatever) no longer distributes this fork (=> uses upstream fuse-ext2 directly?), so, the way I read it, src:fuse-umfuse-ext2 is fuse-ext2 0.0.6.0 + a patchset that ended up upstream by the end of 2009? > 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?
signature.asc
Description: PGP signature