Bug#964265: ITP: exfatprogs -- tools to create, check and label exFAT filesystems
On Sat, Jul 04, 2020 at 02:49:15PM -0400, Nicholas D Steeves wrote:
Hi Nicholas,
> > Since people started to ping me about getting this one introduced
> > I now give in and pick it up. I plan to continue for now the
> > maintenance of the fuse-exfat and exfat-utils packages.
> > While fuse-exfat can be coinstalled at any moment exfat-utils and
> > exfatprogs will for now conflict with each other.
> > Maybe I later on drop the mkfs.exfat and fsck.exfat links from
> > the exfat-utils package.
>
> Might /etc/alternatives also be considered for mkfs.exfat and
> fsck.exfat?
> Also, what about /sbin/mount.exfat? That one also seems
> like a candicate for /etc/alternatives.
Yes I thought about it, I also thought about dropping the symlinks
similar to the mount.exfat helper issue with fuse-exfat.
Right now I believe we should cater for the general use cases which
probably is someone wanting to mount an exfat filesystem with the
most convenient and fast driver, which is the kernel based one.
So if you have a reason to still want to use the fuse driver you
make an explicit choice. That's when I expect you to be able to
invoke the mount.exfat-fuse helper.
One thing to note is that there is no alternative for the mount.exfat
helper, either it's there or it's not. Michael proposed a thin
wrapper in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963752
but I do not believe that helps the average user. That's why I droped
the symlink from the package.
Now back to the utils situation:
Here we could use alternatives, but I believe for the average user that
will be even more confusing. Luckily upstream of the exfatprogs
made the concious decision to not create a naming colision with the
existing exfat-utils package, so user have a chance to recognise
the different upstream sources. I believe it's more straight forward
to let the user select the implementation he prefers and just make
sure we do not have the naming conflict of the binaries.
The other, longterm more likely option from my point of
view, is to drop the mkfs.exfat and fsck.exfat links, and let the user
invoke exfatfsck and mkexfatfs binary provided by the package.
I do not want to make that change right now, and would prefer to
wait a bit if we see some bugs with the exfatprogs implementation,
> Probably tangential: I wonder if this is a case where a virtual package
> (where both the Samsung and the exfat-utils Provide exfat-tools or
> similar) could be considered? As you know, I'm primarily interested in
> backports, and I wonder if whatever the kernel team does with Wireguard
> would be a useful precedent to follow. eg: if newer kernels Provide:
> feature that that was previously wireguard-dkms. 'not sure if that's
> over-engineering dependency and feature resolution though ;-)
I believe the use case here is so narrow that we should keep it as simple
as possible.
Cheers,
Sven
Reply to: