[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#964265: ITP: exfatprogs -- tools to create, check and label exFAT filesystems



On Sun, Jul 05, 2020 at 09:35:14AM +0300, Andrei POPESCU wrote:
> On Sb, 04 iul 20, 19:56:45, sven@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


Reply to: