Bug 429171 - muine issues with mono(..) provides
Summary: muine issues with mono(..) provides
Alias: None
Product: Fedora
Classification: Fedora
Component: muine
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Sindre Pedersen Bjørdal
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2008-01-17 18:37 UTC by Bill Nottingham
Modified: 2014-03-17 03:11 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-02-28 11:26:54 UTC

Attachments (Terms of Use)

Description Bill Nottingham 2008-01-17 18:37:21 UTC
Description of problem:

A muine build provides:

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

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

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


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

mono(TrayIcon) =
mono(InotifyPlugin) =

Any tips on how to get rid of these?

Comment 2 Bill Nottingham 2008-01-18 16:18:03 UTC
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 19:03:44 UTC
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 19:18:48 UTC
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 21:51:58 UTC
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.

Comment 6 Bill Nottingham 2008-01-23 15:30:29 UTC
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 12:20:49 UTC
How can I keep the muine-plugin provides while removing the unwanted ones?

Comment 8 Bill Nottingham 2008-01-24 16:14:17 UTC
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 16:40:06 UTC
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 23:49:32 UTC
Also broken in F9a1, FWIW.

Comment 11 Sindre Pedersen Bjørdal 2008-02-22 09:16:24 UTC
How can I solve this issues?

Comment 12 Sindre Pedersen Bjørdal 2008-02-28 11:26:54 UTC
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.