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
