Bug#989744: libqt5core5a: 5.15.2+dfsg-7 breaks MIME subclassing logic (which breaks some features in e.g. Dolphin)

[Dennis Filder <d.filder@web.de>]

On Sat, Jun 12, 2021 at 02:58:23PM +0300, Dmitry Shachnev wrote:

> Just like Lisandro, I have never tried that.

BTW: My original intention was to use this to edit extended attributes
on files and directories from within Dolphin.

> Please test the attached .deb file. I did not change the version number,
> to make it possible to install only libqt5core5a and not the whole qtbase
> stack.

Thanks.  That indeed brings the behaviour close enough to how it was
before that I would consider it a fix for this bug.  Since the
remaining patch still changes the MIME type decision logic the
behaviour is still somewhat different though.  However, it becomes
difficult for me to tell how different because remembering the exact
details of the previous (5.15.2+dfsg-5) behaviour is not easy as it
never quite worked consistently either.

For example now with the glob pattern "*.*" added to "all/allfiles" a
C source code file "test.c" in Dolphin's list view is listed as being
of type "all files" and also all operations defined for "all/allfiles"
are listed in the context menu, but after selecting "Properties" in
Dolphin's context menu its "Contents" field shows "C source code"
(presumably because Dolphin uses magic-based fingerprinting).  All
this despite the file /usr/share/mime/text/x-csrc.xml defining the
MIME type "text/x-csrc" with the glob pattern "*.c".  I think it has
to do with how user-defined MIME type definitions from
~/.local/share/mime are merged into the set of system-defined ones.
Since KDE System Settings does not allow you to specify a weight value
for your glob patterns (and most under /usr/share/mime/* don't specify
it either) the merging does not actually always yield sensible results
as almost all glob patterns end up having the default weight of 50.
And it also leads to behaviour that is difficult to reproduce across
setups.

I just wished the KDE devs would actually try a little harder to make
all this MIME type handling more consistent (and easier to
investigate) and to make the MIME types "all/all" and "all/allfiles"
behave as you would expect.  But I guess that belongs in a separate
bug report.

Regards,
Dennis.