Summary: | Should not complain (accept as valid) about mime-types starting with zz-application | ||
---|---|---|---|
Product: | desktop-file-utils | Reporter: | Hans de Goede <jwrdegoede> |
Component: | general | Assignee: | Hans Petter Jansson <hpj> |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | medium | ||
Version: | unspecified | ||
Hardware: | Other | ||
OS: | All | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: | PATCH: mimeutils: deal with various zz-application/zz-winassoc-XXX mime types |
Description
Hans de Goede
2011-09-28 03:05:13 UTC
Sure, patch welcome :-) Btw, I realize we mark zz-application/zz-winassoc-cdr as discouraged. This might be a good approach too for zz-application/zz-winassoc-xls and others (although I understand the argument that this mime type might be referenced in old mails) Created attachment 51795 [details] [review] PATCH: mimeutils: deal with various zz-application/zz-winassoc-XXX mime types Hi, (In reply to comment #2) > Btw, I realize we mark zz-application/zz-winassoc-cdr as discouraged. This > might be a good approach too for zz-application/zz-winassoc-xls and others > (although I understand the argument that this mime type might be referenced in > old mails) I've been thinking a bit about this. I think discouraging them is the right thing to do in general. But for types which apps really want to claim for interoperability reasons, and thus consciously claim like gnumeric upstream refusing to stop using zz-application/zz-winassoc-xls, discouraging them does not help. Discouraging these will still cause update-desktop-database to complain, which as experience shows (see google results for zz-application/zz-winassoc-xls), leads to lots of bugreports for all distributions. So I've come up with a patch which makes mimeutils deal with this in 2 different ways: 1) For the "popular" ones (doc and xls) simply accept them 2) For the others, advice the standard mime type for these files I hope this is an acceptable solution. If it is the patch is git format-patch output, so all you need to do is git am it :) Regards, Hans I've been thinking about this again. We probably need to update shared-mime-info to have all the aliases you added here, as well as aliases for zz-application/zz-winassoc-doc and zz-application/zz-winassoc-xls. And once we get those last two aliases, I'm actually unsure we need to put those two as exceptions -- I would think that our mime stack would be clever enough to think: "want to open zz-application/zz-winassoc-xls, which is an alias to application/vnd.ms-excel, so want to open application/vnd.ms-excel". What do you think? (In reply to comment #4) > I've been thinking about this again. We probably need to update > shared-mime-info to have all the aliases you added here, as well as aliases for > zz-application/zz-winassoc-doc and zz-application/zz-winassoc-xls. > That sounds like a good idea. > And once we get those last two aliases, I'm actually unsure we need to put > those two as exceptions -- I would think that our mime stack would be clever > enough to think: "want to open zz-application/zz-winassoc-xls, which is an > alias to application/vnd.ms-excel, so want to open application/vnd.ms-excel". > > What do you think? I think that wrt "our mime stack would be clever enough", that the proof is in the pudding. IOW we need to make sure that is the case (and then convince the gnumeric people of this and that since the alias is now in shared-mime-info, that they can drop it from their desktop file). I've no idea how to quickly / easily test this though, and I don't have a lot of time to spend on this. So I would like to move forward with my latest patch for now, I'll also do a patch for shared-mime-info, and then maybe later we can see if the aliases can be removed from desktop files since our mime infra takes care of it. Hans: first, thanks for your time :-) So I checked our mime system is sane: - application/x-wordperfect is an alias for application/vnd.wordperfect - $ grep -rl application/x-wordperfect /usr/share/applications/ $ - $ grep -rl application/vnd.wordperfect /usr/share/applications/ /usr/share/applications/defaults.list /usr/share/applications/writer.desktop /usr/share/applications/mimeinfo.cache - $ gvfs-mime --query application/x-wordperfect Default application for 'application/x-wordperfect': writer.desktop Registered applications: writer.desktop So it works as expected. I'll talk to the gnumeric people. I committed your patch, and then changed them all to aliases. This depends on the following bugs in shared-mime-info to work really properly, though: bug 41989, bug 41708, bug 36036, bug 41680, bug 41684. Hi, this bug has been closed, however the error message is still there in Debian sid and Ubuntu 14.10: # update-desktop-database Warning in file "/usr/share/applications/gnumeric.desktop": usage of MIME type "zz-application/zz-winassoc-xls" is discouraged ("zz-application/zz-winassoc-xls" should be replaced with "application/vnd.ms-excel") Sorry for the noise, reassigning to new maintainer. (In reply to Laurent Bonnaud from comment #8) > Hi, > > this bug has been closed, however the error message is still there in Debian > sid and Ubuntu 14.10: > > # update-desktop-database > Warning in file "/usr/share/applications/gnumeric.desktop": usage of MIME > type "zz-application/zz-winassoc-xls" is discouraged > ("zz-application/zz-winassoc-xls" should be replaced with > "application/vnd.ms-excel") It's a different message, though -- the original bug is about zz-application being an unregistered media type. It was addressed by adding aliases to shared-mime-info and a new message to desktop-file-utils suggesting that the application's MIME type associations be updated. I think the idea was that the Gnumeric maintainers could be convinced to switch over to the preferred MIME types while remaining compatible with the old ones thanks to the aliases. The solution has been around for a couple of years now and should be widely deployed. I'll ping them again and ask if they're ready to switch. Bug 75014 exists, we can continue there. I'll close this one again. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.