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?

Attachment: signature.asc
Description: PGP signature

Reply via email to