Bug 754719 - kde-settings owns mimeapps.list
kde-settings owns mimeapps.list
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: kde-settings (Show other bugs)
16
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Rex Dieter
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-11-17 09:24 EST by Jeremy Sanders
Modified: 2011-11-28 10:10 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-11-28 10:10:49 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Jeremy Sanders 2011-11-17 09:24:07 EST
The file mimeapps.list is supposed to be a file for allowing a sysadmin for changing default application or mime associations - see http://www.freedesktop.org/wiki/Specifications/mime-actions-spec . However, kde-settings owns the file /usr/share/kde-settings/kde-profile/default/share/applications/mimeapps.list

On a F16 system it contains:
[Added Associations]
application/x-bittorrent=kde4-ktorrent.desktop;kde4-kget.desktop;
application/x-rpm=kde4-apper.desktop;gpk-install-file.desktop;

I think this stuff should be in defaults.list rather than mimeapps.list. I also don't see why kde-settings owns mimeapps.list. If it does, it should mark it as a configuration file so that sysadmin modifications are not overwritten when the package is upgraded.

Version-Release number of selected component (if applicable):
kde-settings-4.7-13.fc16.4.noarch
Comment 1 Rex Dieter 2011-11-17 09:42:22 EST
It's not that simple. :(

Note the spec says "This hasn't been finalized in a cross-desktop way yet..."

In short,
Gnome uses defaults.list
KDE uses a combination of InitialPreference key in the .desktop files and mimeapps.list

Let me see if I can come up with a solution for you (though the %config suggestion has some merit too)
Comment 2 Kevin Kofler 2011-11-17 10:00:49 EST
Marking files under /usr as %config doesn't strike me as that great an idea. I think we should prepend a directory under /etc to the default search path, like we did for the KConfig search path (see kdelibs-4.6.90-kstandarddirs.patch). In this case, it should be enough to create /etc/kde/xdgdata/applications and prepend /etc/kde/xdgdata to the XDG_DATA_DIRS path.
Comment 3 Rex Dieter 2011-11-17 10:18:08 EST
on the other hand, perhaps we could shuffle the ordering a bit to allow use of /usr/local for this purpose as well, ie, move /usr/local/share priority to be higher than /usr/share/kde-settings/kde-profile/default/share ?
Comment 4 Rex Dieter 2011-11-17 10:19:29 EST
though in doing so, I'd loathe the bug reports from other installers mucking with /usr/local (chrome, acroread), breaking stuff, and our having to explain why it's their and not our fault. :(
Comment 5 Kevin Kofler 2011-11-17 10:24:15 EST
Yeah, the directory the proprietary crap dumps its crap into shouldn't be trusted any more than /dev/urandom as a source of user preferences. ;-)
Comment 6 Rex Dieter 2011-11-28 10:10:49 EST
So, I guess we're happy with the status quo? (I'll mark WORKSFORME then)

Note You need to log in before you can comment on or make changes to this bug.