Bug 429171 - muine issues with mono(..) provides
muine issues with mono(..) provides
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: muine (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Sindre Pedersen Bjørdal
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-01-17 13:37 EST by Bill Nottingham
Modified: 2014-03-16 23:11 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-02-28 06:26:54 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 Bill Nottingham 2008-01-17 13:37:21 EST
Description of problem:

A muine build provides:

mono(InotifyPlugin) = 0.0.0.0
mono(NDesk.DBus) = 1.0.0.0
mono(NDesk.DBus.GLib) = 1.0.0.0
mono(TrayIcon) = 0.0.0.0

Those look like things that should be only provided by ndesk-dbus, etc.

Version-Release number of selected component (if applicable):

muine-0.8.8-3.fc9
Comment 1 Sindre Pedersen Bjørdal 2008-01-18 07:30:31 EST
Using system ndesk-dbus and ndesk-dbus-glib packages instead of the bundled
removed the NDesk.Dbus provides. Which leaves me with:

mono(TrayIcon) = 0.0.0.0
mono(InotifyPlugin) = 0.0.0.0

Any tips on how to get rid of these?
Comment 2 Bill Nottingham 2008-01-18 11:18:03 EST
Doesn't appear to be provided by anything else, so maybe they're not generic
bindings. If they aren't generic, they should probably be renamed so they're
something like mono(muine-TrayIcon). That's an issue for upstream, though.
Comment 3 Sindre Pedersen Bjørdal 2008-01-18 14:03:44 EST
They aren't generic, but after talking to upstream I couldn't quite convince
them that the current names even existed, much less that they needed to be
changed. Seems this way of naming stuff is common, other mono apps have similar
issues, see banshee. 

How do I proceed from here?
Comment 4 Bill Nottingham 2008-01-18 14:18:48 EST
If the mono APIs that it's exporting aren't actually for public
consumption/other apps to use, adding:

%define __mono_provides %{nil}

to the spec should remove them. Although, if that's the case, the mono-provides
script should probably be fixed (that would be an RPM bug.)

If they are for public consumption, then don't do anything.
Comment 5 Sindre Pedersen Bjørdal 2008-01-22 16:51:58 EST
They aren't for public consumption, so I've removed them. As for fixing the
mono-provides script, I have no idea how, but agree something should be done.

Muine updates in devel and in F8 and F7 testing as soon as I get around to it.
Thanks.
Comment 6 Bill Nottingham 2008-01-23 10:30:29 EST
Whoops, looking at the rawhide report, it appears that the provide for
mono(muine-plugin) needs kept, otherwise it can't install.
Comment 7 Sindre Pedersen Bjørdal 2008-01-24 07:20:49 EST
How can I keep the muine-plugin provides while removing the unwanted ones?
Comment 8 Bill Nottingham 2008-01-24 11:14:17 EST
Good question. Probably by overriding the mono provides and requires, and
filtering them via grep or something similar. (This is getting pretty ugly
pretty quick.) Maybe not filtering is best in the short run, and just making
sure that it uses things like the system ndesk-dbus where appropriate.
Comment 9 Luis Villa 2008-01-26 11:40:06 EST
BTW, since this now blocks installation of the muine in updates-testing, this
should probably be prioritized as something other than low-low. (And maybe
retitled to make it easier to find.)
Comment 10 Luis Villa 2008-02-21 18:49:32 EST
Also broken in F9a1, FWIW.
Comment 11 Sindre Pedersen Bjørdal 2008-02-22 04:16:24 EST
How can I solve this issues?
Comment 12 Sindre Pedersen Bjørdal 2008-02-28 06:26:54 EST
Issue finally resolved. Turned out commenting didn't do the trick, actually
removing the troubled mono provides line fixed it. 

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