Bug#993100: bullseye-pu: package udisks2/2.9.2-2+deb11u1
On Sat, Dec 04, 2021 at 12:35:17PM +0100, Michael Biebl wrote:
> Am 03.12.2021 um 15:21 schrieb Julien Cristau:
Hi,
> > How compatible are exfat-utils/exfatprogs? E.g. could this cause
> > unexpected results (outside of udisks) for a user system that switched
> > to exfatprogs as a result of this?
It depends. If you only look at the "create a filesystem with a proper
label" it's compatible, and there is an explicit compatibility fallthrough
https://github.com/exfatprogs/exfatprogs/blob/master/mkfs/mkfs.c#L615
If you look beyond that I did not verify it for each and every tool.
Looking just at the case of udisks2 the invocation of mkfs.exfat and
exfatlabel are compatible. Though I did not try it out myself, did someone
already try out udisks2 on bullseye with exfatprogs?
Regarding the patch proposed here, I would use an alternation for the
recommends, exfatprogs | exfat-utils? I believe the core issue here is
not known bugs in exfat-utils as shipped in bullseye, but that I created
a mess by introducing exfatprogs shortly before the freeze, and some
packages switched to it and others did not. Now we have a stable
release with two conflicting implementations, because I did not want to ensure
on short notice that each and every tool is compatible. But users would like
to use software stacks together, where some depend on exfat-utils and others on
exfatprogs.
In hindsight just uploading it with a conflict on each other was a bad
idea. But shipping bullseye without exfatprogs at all, also did not seem
like a brilliant choice.
> The command line tools are (mostly) compatible. I'm only aware of the
> issue detailed at https://github.com/storaged-project/udisks/issues/882
> i.e. exfat-utils provides a mkextfatfs tool, whereas exfatprogs doesn't
>
> It is my understanding that exfatprogs is the vastly superior implementation
> and we should prefer it over the FUSE based one.
exfat-utils does not rely on FUSE itself, it just shares a lot of code
with the fuse driver. After all it's the same single developer who wrote
both things.
exfatprogs is maintained by the Samsung guys who wrote the Linux exFAT
implementation. It's the implementation with more development momentum
right now, and probably more widespread due to the use in the Android
context. Also I believe the fsck.exfat implementation actually can fix
stuff. The one from exfat-utils was mostly a debugging aide, and only
started to actually do some fixing in the last release.
Does that already make it superior? Maybe.
The plan for unstable is to get rid of exfat-fuse and exfat-utils asap, because
I've enough trust by now in the Linux exFAT driver and it's faster. I'm waiting
just for libguestfs as the last reverse depedency to switch, because the fallout
of an uninstallable libguestfs is quite a mess.
HTH,
Sven
Reply to: