Red Hat Bugzilla – Bug 169332
Gnumeric ships with bogus /usr/share/mc/templates/gnumeric.desktop file
Last modified: 2007-11-30 17:11:14 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050909 Fedora/1.7.10-1.5.2 Description of problem: gnumeric ships /usr/share/mc/templates/gnumeric.desktop However no parent package owns /usr/share/mc/templates (mc is not a parent package of gnumeric) I.e. if installing gnumeric without having mc installed, /usr/share/mc/templates and /usr/share/mc are unowned Version-Release number of selected component (if applicable): gnumeric-1.4.3-2.1 How reproducible: Always Steps to Reproduce: 1. yum install gnumeric 2. yum remove mc 3. rpm -qf /usr/share/mc /usr/share/mc/templates Actual Results: # rpm -qf /usr/share/mc /usr/share/mc/templates file /usr/share/mc is not owned by any package file /usr/share/mc/templates is not owned by any package This causes these directories to stay around orphaned/unowned upon removing the gnumeric rpm. Expected Results: gnumeric should own /usr/share/mc /usr/share/mc/templates Alternatively, /usr/share/mc/templates/gnumeric.desktop should not be shipped. Additional info:
Yet another alternative would be to put /usr/share/mc/templates/gnumeric.desktop into a subpackage (e.g. gnumeric-mc) and let this subpackage Requires: mc
Thanks for reporting, I'll just own the dir instead of creating yet another subpackage. I concider this bug not worthy of a new release though, I'll fix it when something that thus warrant a new release comes along.
Hmm, this bug has long been "fixed" by a newer release I just forgot to close it, on closer examination though it turns out that mc itself doesn't own /usr/share/mc/templates only /usr/share/mc as /usr/share/mc/templates doesn't seem to get used by mc at all, and the gnumeric.desktop file _really_ is a .desktop file, so I'm leaving this bug open to track the fact that this entire fire should be removed from the gnumeric package.
I've fixed this for the devel branch its also fixed in FC-5 cvs but I don't want to push a build there purely for this small fix. Once there is reason for a build on FC-5 this will get picked up too.