Shared Mime spec: overriding globs locally

[Alexander Larsson]

On Sat, 2009-03-21 at 13:02 +0100, David Faure wrote:
> If a user wants to modify the globs for a given mimetype, I generate
> a local ~/.local/share/mime/packages/<mimetype>.xml file with 
>  <glob pattern="..."/> in it, run update-mime-database, and then the parsing 
> of the generated ~/.local/share/mime/globs file is supposed to *override*
> the system definitions with the local ones (not "add to"), right?
> (This particular behavior isn't fully defined in the spec, it doesn't explicitely
> say what happens with local overrides)

Yeah, thats not really specified. I don't know what the gnome code does
in this case even. Lemme look... back. They are all added.

> But the main problem is: this only works when adding or modifying globs for a mimetype
> (more precisely when the mimetype has at least one glob in the end)
> What if the user wants to *remove* all globs for this mimetype?
> (use case: first 3 paragraphs in https://bugs.kde.org/show_bug.cgi?id=184181)

Didn't we make things work with conflicting globs? It should fall back
to sniffing and if that doesn't work then use the weights to decide
which one is the default?

> Then it doesn't work, because in that case the local globs file contains
> nothing about the mimetype, so the system-wide globs are still used, which
> is not what the user requested.

I'm not sure exactly what you mean here. 

> Solutions?
> 
> I can think of only one: extending the spec to contain something like <glob deleteall="true"/>,
> and letting update-mime-database generate a line that says
> mimetype:__NOGLOBS__
> in the local globs file.
> 
> What do you think? Any other solution?

For the reported case, can't we just handle the conflict and pick the
glob weights according to the preferences of the user?

Although in general that doesn't solve the issue, so maybe we could add
the delete feature. 

If so, what is the order of directories being searched? (I assume
__NOGLOBS__ expire things from all previously read dirs.

i.e. if XDG_DATA_HOME=~/.local/share and XDG_DATA_DIR=/foo1:/foo2

which order are they searched? XDG_DATA_HOME last probably.

> P.S.: While we're at it we could do exactly the same for "magic" bits: specify that
> local definitions *override* global ones (not "add to"), and that a custom
> entry means "remove all global definitions for this mimetype". Not that I provide
> any GUI for editing magic bits, but this would make it possible to do the equivalent
> of "deleting" a system mimetype altogether: if it has no magic and no globs,
> it is effectively unused for local files, even if its name keeps existing (which is good,
> for the case of e.g. getting a mail with that mimetype name for an attachment).

I don't see why not.