Bug#989744: libqt5core5a: 5.15.2+dfsg-7 breaks MIME subclassing logic (which breaks some features in e.g. Dolphin)
Package: libqt5core5a
Version: 5.15.2+dfsg-7
Severity: normal
X-Debbugs-CC: Dennis Filder <d.filder@web.de>
Dear Maintainer,
yesterday evening I upgraded the binary packages for
src:qtbase-opensource-src from 5.15.2+dfsg-5 to 5.15.2+dfsg-7. After
today's boot I noticed that all the file type associations in Dolphin
are broken. All files only have the associations for the type
"all/allfiles" and directories those for type "all/all" rendering
Dolphin effectively unusable.
On a hunch I removed the glob patterns "*.*", "*.a*", and "*.j*"
(which I had added years ago since it was the only way to add
operations to all file types without adding a million MIME types
explicitly to the corresponding .desktop files) from the type
"all/allfiles" in System Settings -> Applications -> File Associations
and hit "Apply" while leaving "*" (which for some reason never worked
on its own) untouched. Restarting Dolphin then restored the normal
behaviour (but without my operations for all file types, of course).
The changelog tells me that d/patches/mime_globs.diff was added
recently to fix something regarding the MIME type determination logic,
so that's probably the cause.
I cannot tell whether this is a bug in QMimeType provided by
qtbase-opensource-src or in a different component elsewhere that
merely uses QMimeType to find lists of applications association
definitions, but now broke due to changes in its behaviour.
The thing is: Wanting to associate certain applications to all file
types is a perfectly legitimate use-case, and it used to work. The
Shared MIME-info Database specification mentions the concept of
subclassing (§ 2.11. Subclassing), and it should allow for exactly
this. MIME types in a subclassing relationship should have their
application association definitions collected additively for the user
to choose from, and one association should not be able to just
overshadow all others.
The spec does not mention the MIME types "all/all" and "all/allfiles",
but Qt clearly defines them for the purpose of subclassing, and
already contains implicit subclassing logic for them. The Qt
developers need to decide if they want to continue to offer this
feature by either fixing what broke or removing the MIME types
"all/all" and "all/allfiles" on account of being both
ineffective/superfluous and non-standard.
N.B.: In my search for a workaround I found out that unfortunately it
is not possible to associate an application with a wildcard MIME type
by adding e.g. "MimeType=video/*;" to a .desktop under
~/.local/share/applications/.
Regards,
Dennis Filder.
-- System Information:
Debian Release: 11.0
APT prefers testing-security
APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-7-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_DE.UTF-8, LC_CTYPE=en_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: default
Versions of packages libqt5core5a depends on:
ii libc6 2.31-12
ii libdouble-conversion3 3.1.5-6.1
ii libgcc-s1 10.2.1-6
ii libglib2.0-0 2.66.8-1
ii libicu67 67.1-6
ii libpcre2-16-0 10.36-2
ii libstdc++6 10.2.1-6
ii libzstd1 1.4.8+dfsg-2.1
ii shared-mime-info 2.0-1
ii zlib1g 1:1.2.11.dfsg-2
Versions of packages libqt5core5a recommends:
pn qttranslations5-l10n <none>
Versions of packages libqt5core5a suggests:
ii libthai0 0.1.28-3
-- no debconf information
Reply to: