Bug#989744: libqt5core5a: 5.15.2+dfsg-7 breaks MIME subclassing logic (which breaks some features in e.g. Dolphin)
Control: tag -1 moreinfo
Hi!
On Fri, 11 Jun 2021 at 13:33, Dennis Filder <d.filder@web.de> wrote:
>
> 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/.
This really sounds like a use case that was possible due to the bug,
and the fix broke that path. According to the patch:
This change also optimizes QMimeBinaryProvider::addFileNameMatches
to have the same logic as xdgmime for glob matching:
literals > extensions > other globs
How does xdgmime behaves in your specific case? If xdgmime behaves
differently then we definitely can call this a bug, but if the
behavior is the same then not.
--
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/
Reply to: