Package: libqt5core5a Version: 5.15.2+dfsg-7 Severity: normal X-Debbugs-CC: Dennis Filder <d.fil...@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
