Why not have the same list for application/x-zip and application/zip? If those two content types are aliases, then mimeapps.list is not being consistent. How are you proposing that GLib merges the conflicting values?

I'd expect the merging to be:
- first, the canonical mime-type handlers, in order
- second, the alias mime-types handlers, in order
- remove trailing duplicates

I don't see anything in the spec that mentions how this should behave. It seems bizarre that latching onto an alias would override the canonical handler.

Ping here?

(In reply to Carlos Soriano from comment #3)
> Ping here?

Sorry, I’m having enough trouble keeping up with patch review, let alone writing new patches. If you could provide a patch I should be able to find time to review it. Please include test cases.

(In reply to Bastien Nocera from comment #2)
> I'd expect the merging to be:
> - first, the canonical mime-type handlers, in order
> - second, the alias mime-types handlers, in order
> - remove trailing duplicates
> 
> I don't see anything in the spec that mentions how this should behave. It
> seems bizarre that latching onto an alias would override the canonical
> handler.

From my reading of the spec, the only relevant paragraph seems to be here: https://specifications.freedesktop.org/shared-mime-info-spec/shared-mime-info-spec-0.18.html#idm140001680036896

> alias elements indicate that the type is also sometimes known by another name, given by the type attribute. For example, audio/midi has an alias of audio/x-midi. Note that there should not be a mime-type element defining each alias; a single element defines the canonical name for the type and lists all its aliases. 

and it says nothing about aliases being treated separately from what they alias. I’d be inclined to ignore any MIME type handlers set for a MIME type which is an alias of another. Merging would be non-trivial to do, especially since it would be a way of recovering from a MIME type handler list which is invalid (it specifies a handler for an alias).

(In reply to Philip Withnall from comment #4)
> (In reply to Carlos Soriano from comment #3)
> > Ping here?
> 
> Sorry, I’m having enough trouble keeping up with patch review, let alone
> writing new patches. If you could provide a patch I should be able to find
> time to review it. Please include test cases.
> 

Sure, just wanted to check if the approach of Bastien makes sense to you.

> (In reply to Bastien Nocera from comment #2)
> > I'd expect the merging to be:
> > - first, the canonical mime-type handlers, in order
> > - second, the alias mime-types handlers, in order
> > - remove trailing duplicates
> > 
> > I don't see anything in the spec that mentions how this should behave. It
> > seems bizarre that latching onto an alias would override the canonical
> > handler.
> 
> From my reading of the spec, the only relevant paragraph seems to be here:
> https://specifications.freedesktop.org/shared-mime-info-spec/shared-mime-
> info-spec-0.18.html#idm140001680036896
> 
> > alias elements indicate that the type is also sometimes known by another name, given by the type attribute. For example, audio/midi has an alias of audio/x-midi. Note that there should not be a mime-type element defining each alias; a single element defines the canonical name for the type and lists all its aliases. 
> 
> and it says nothing about aliases being treated separately from what they
> alias. I’d be inclined to ignore any MIME type handlers set for a MIME type
> which is an alias of another. Merging would be non-trivial to do, especially
> since it would be a way of recovering from a MIME type handler list which is
> invalid (it specifies a handler for an alias).

So the best approach is basically to ignore aliases right?

(In reply to Carlos Soriano from comment #5)
> So the best approach is basically to ignore aliases right?

To ignore MIME handlers set for MIME types which are aliases of other MIME types.

That’s the approach I would look at implementing. However, I haven’t touched the MIME handler code before, and so this is only based on my reading of the spec and what’s in this bug. I would appreciate Bastien’s thoughts on what I’m proposing.

(In reply to Philip Withnall from comment #6)
> (In reply to Carlos Soriano from comment #5)
> > So the best approach is basically to ignore aliases right?
> 
> To ignore MIME handlers set for MIME types which are aliases of other MIME
> types.

That's not what you want to do. The typical mime-type life will start as a "found in the wild" mime-type, which applications will then start to use. Once IANA and the format creator get to it, it will have a new official mime-type, and we'll use it in shared-mime-info for that type, and relegate the old mime-type to alias status, so applications don't have to be updated straight away.

What you don't want is, when parsing defaults, is for the alias to be handled with a higher priority as the new mime-type.

To get this sorted, I would first write a test case for the problem in glib, which we'd check fails, disable it, and probably fix the problem in the mimeapps.list until we can find someone that can spend the time on fixing it. I've never touched the glib/gio code for mime-type handling either.

That makes sense, thanks for the explanation Bastien. In that case, the approach from comment #2 makes sense indeed.

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/1298.