dosfstools in extra over rules Debian's 4.2 - is 2021 calamares fix still need?

[minixjr]

dosfstools in extra overrides Debian's 4.2 - is the 2021 calamares fix needed?

While comparing the siduction repositories against Debian I came across dosfstools.
It is one of the very few packages where the siduction version still wins over a
newer one from Debian, and I am not sure whether that is still intended.

Code Select Expand

$ apt policy dosfstools
dosfstools:
  Installed:            4.2-1.1~really4.1-2
  Candidate:            4.2-1.1~really4.1-2
  Version table:
 *** 4.2-1.1~really4.1-2 500
        500 https://packages.siduction.org/extra unstable/main amd64 Packages
    4.2-1.2 500
        500 https://deb.debian.org/debian unstable/main amd64 Packages
The changelog of the installed package says:

Code Select Expand

dosfstools (4.2-1.1~really4.1-2) unstable; urgency=medium
  * Non-maintainer upload.
  * fix for calamares
What seems to happen: dpkg splits version and revision at the LAST hyphen, so the
comparison is "4.2-1.1~really4.1" against "4.2" - and anything that follows "4.2"
sorts higher than "4.2" alone:

Code Select Expand

dpkg --compare-versions '4.2-1.1~really4.1-2' gt '4.2-1.2' && echo higher  # prints: higher
So the package does not just outrank the 4.2-1.1 it was meant to replace back then,
it outranks every future 4.2-x as well. Debian is at 4.2-1.2 now, but with extra
enabled we keep getting the 4.1 content, and nothing indicates that on the machine.

My question - and I may well be missing something here: is the calamares problem
from 2021 still present? If it is, everything is as intended and please ignore me.
If it is not, the package could probably be dropped from extra so that Debian's
version takes over again.

I have no idea what exactly broke in 4.2 at the time, so I cannot judge myself
whether it still matters.

[der_bud]

Some more background to the dosfstools case in 2021:
https://news.siduction.org/2021/02/siduction-2021-1-1-c-blues-point-release/ 
https://forum.siduction.org/index.php?topic=8250.msg66581#msg66581 

[minixjr]

Thanks, @der_bud - that answers the "why". For the record, from the 2021 release
announcement:

A new version 4.2 of dosfstools prevents kpmcore, which sits at the heart
of KDE Partition Manager and gets utilized in Calamares, to create GPT partitions.
Dosfstools no longer allows empty labels, but it also changed the way labels are
reset. In the specific use case of creating a fat32 partition for the ESP, there
is no label to reset as the partition does not exist yet.

So the trigger was never a dosfstools bug, but kpmcore asking fatlabel to reset a
label that did not exist yet. I checked both halves of that here.

1. dosfstools still behaves exactly as in 2021.
With Debian's current 4.2-1.2, setting an empty label fails:

Code Select Expand

fatlabel esp.img ""    # 4.2: exit 1, "labels can't be empty or white space only"

With the 4.1 from extra the same call succeeds silently. That part is unchanged.

2. But kpmcore no longer makes that call.
In kpmcore 26.04.0 (current in Debian), fat12::writeLabel - which fat16 and fat32
inherit - reads:

Code Select Expand

const QString label = newLabel.isEmpty() ? QStringLiteral("-r") : newLabel;
ExternalCommand cmd(report, QStringLiteral("fatlabel"), { deviceNode, label });

An empty label becomes "fatlabel -r", the option dosfstools 4.2 introduced for
removing a label. The label job still runs even when there is nothing to set;
a comment in newoperation.cpp says that is deliberate.

3. And that is where the downgrade hurts today.
4.1 does not know -r, so it takes it as the label text. On a plain image file,
no root required:

Code Select Expand

truncate -s 64M t.img
mkfs.fat -F32 -n TESTLABEL t.img
fatlabel t.img -r
fatlabel t.img

    with dosfstools 4.1 (extra)  ->  prints "-r"      exit 0, only a lowercase warning
    with dosfstools 4.2 (Debian) ->  prints nothing,  label removed

So today's kpmcore expects dosfstools 4.2, while extra supplies 4.1. Creating a
FAT partition without a label, or clearing one, leaves a partition literally
labelled "-r" - silently, with exit code 0. Unlike 2021 this is not limited to
fresh installs: it hits installed systems using partitionmanager, which is where
the package from extra is active.

Which brings me back to my question. As far as I can tell the 2021 downgrade is
not merely unnecessary today - it produces the kind of breakage it was meant to
prevent. Dropping dosfstools from extra would hand the job back to Debian's
4.2-1.2.

One limitation: I did not re-run this through Calamares or KDE Partition Manager
itself. The fatlabel behaviour above is measured on this machine with both
binaries side by side; the kpmcore part is read from the 26.04.0 sources.

---
Worked out together with Claude Code (Opus 5).