Hi! On Tue, 2024-10-22 at 00:00:21 +0200, Ben Hutchings wrote: > 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?
> > > 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.) > > 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. Alternatively you could instead package this as src:fuse-ext2 bin:fuse-ext2 both without an epoch, and if you want to transition the old users off bin:fuseext2 then provide that as well for a transition period with the old version prefixed (say 0.4+0.0.11-1, which can be constructed dynamically at build time). Using fuse-ext2 would match the naming convention of many of the existing fuse package, would match the main program name (fuseext2 being a compat symlink), and would make the source and binary packages match name which seems like a bonus anyway. And epochs are forever, and reset any existing versioned dependencies, including for local/custom packages where we have no visibility. Thanks, Guillem
