Hi! On Tue, Oct 22, 2024 at 02:08:47PM +0200, Guillem Jover wrote: > 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). I kinda wanted to do something like this, but didn't think having a different source/binary version was possible! It looks like I just need to call {dh_,dpkg-}gencontrol different, thanks.
> Using fuse-ext2 would match the naming convention of many of the existing
> fuse package,
Honestly this kinda seems like a wash
fuse2fs fuseext2 fusefat fusefile fuseiso fuseiso9660
fuse-convmvfs fuse-overlayfs fuse-posixovl fuse-zip
afuse ifuse squashfuse
ceph-fuse exfat-fuse gnunet-fuse gvfs-fuse kio-fuse openafs-fuse
owfs-fuse rbd-fuse unionfs-fuse xrootd-fuse zfs-fuse
(the prevailing trend looks like "$homepage" ~ fuse || "$homepage-fuse" ~=
s/-fuse-fuse/-fuse/).
...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.
> 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.
Agree on all fronts this would be better.
> And epochs are forever, and reset any
> existing versioned dependencies, including for local/custom packages
> where we have no visibility.
I don't suspect there are that many but this is also fair
(and explains the policy's anti-epoch stance better than policy did).
Thoughts?
наб
signature.asc
Description: PGP signature
