On Sun, Jul 05, 2020 at 09:35:14AM +0300, Andrei POPESCU wrote: > On Sb, 04 iul 20, 19:56:45, s...@stormbind.net wrote: > > While fuse-exfat can be coinstalled at any moment exfat-utils and > > exfatprogs will for now conflict with each other. > > Isn't this the typical use-case for alternatives?
IMO sensible if you have two packages which are likely to be coinstalled often. For those kind of niche tools I've here I do not want user to be bothered to figure out which alternative is selected and which he would actually like to use. Additionally the native names of the tools shipped in exfat-utils are /sbin/dumpexfat /sbin/exfatfsck /sbin/exfatlabel /sbin/mkexfatfs So probably the midterm will be that the exfatprogs provide the kind of "official" mkfs.exfat and fsck.exfat tools. But for now I prefer to keep the already tested exfat-utils in place. If you want to rely on the exfatprogs tools I assume that is a conscious decision and you're ok with letting go of the exfat-utils implementation. In case there is some overboarding interest in always having both installed, and bothering user with managing alternatives in case he'd like to switch between implementations, I might change that. But for now I do not believe it would offer value for the average user. The only case I can imagine right now that would break is desktop environment 1 depends on exfatprogs and desktop environment 2 depends on exfat-utils and a user has both DEs installed. But even here using alternatives might call for bad surprises when parameter differ. So I believe even in this case we are all better off for now if the packages conflict and thus make clear that they are different tools, and should not be installed in parallel, at least not with the same binary names. (I did not yet check if they are flag by flag compatible or not) Cheers, Sven
