Hi,
Recently I've tried to use "rpmdev-rmdevelrpms" and I've stumbled over a strange dependency chain regarding some mono packages.
Installing banshee requires eventually glib2-devel and so "rpmdev-rmdevelrpms" won't work since it can't remove glib2-devel without uninstalling banshee, too.
The dependency chain is in F10:
banshee -> boo -> nant -> mono-sharpcvslib -> mono-nunit-> glib2-devel
and in rawhide:
banshee -> mono-nunit -> glib2-devel and banshee -> nant and banshee -> boo -> nant
Since in general a normal (user-)programs should not pull in any development packages for a couple of good reasons I'd like to bring this topic to your attention. ;)
What do you think - does it make sense to spend some effort into trying to avoid these problems?
If yes, what could be done with the problem above? I would assume since banshee needs boo for the scripting interface, that boo should not depend itself on nant... ( and in rawhide banshee should neither depend on nant nor mono-nunit, too ).
Best regards, Christian
On Sun, Sep 27, 2009 at 6:09 AM, Christian Krause chkr@fedoraproject.org wrote:
Hi,
Recently I've tried to use "rpmdev-rmdevelrpms" and I've stumbled over a strange dependency chain regarding some mono packages.
Installing banshee requires eventually glib2-devel and so "rpmdev-rmdevelrpms" won't work since it can't remove glib2-devel without uninstalling banshee, too.
The dependency chain is in F10:
banshee -> boo -> nant -> mono-sharpcvslib -> mono-nunit-> glib2-devel
and in rawhide:
banshee -> mono-nunit -> glib2-devel
I plan to turn this off when 1.6 final comes out. Building Banshee with tests unfortunately result in mono-nunit becoming a runtime dependency :(
and banshee -> nant
I don't see this. Apart from the nunit problem, which will be fixed soon, there's only the Boo problem, which I address below.
and banshee -> boo -> nant
The nant thing is annoying, indeed. We could split off Boo.NAnt.Tasks.dll into a separate subpackage or put it in boo-devel. Paul, thoughts?
Once we fix both of these in -devel, we can probably build these for F-12 and get these manually tagged (beta freeze is in effect).
banshee -> boo -> nant
The nant thing is annoying, indeed. We could split off Boo.NAnt.Tasks.dll into a separate subpackage or put it in boo-devel. Paul, thoughts?
Once we fix both of these in -devel, we can probably build these for F-12 and get these manually tagged (beta freeze is in effect).
Hey,
sorry for answering that late but my notebooks energy supply broke down and I'm still waiting for the new one to arrive.
Seems like a good idea to put Boo.NAnt.Task.dll in boo-devel. However I do not understand why there's a dependency. In the spec-file itself there're only BuildRequires which shouldn't make problems. I can't make any changes at least for the next week, so feel free to fix this if you have some spare time.
kind regards, Paul
Hullo,
On Wed, Sep 30, 2009 at 12:05 PM, Paul Lange palango@gmx.de wrote:
banshee -> boo -> nant
The nant thing is annoying, indeed. We could split off Boo.NAnt.Tasks.dll into a separate subpackage or put it in boo-devel. Paul, thoughts?
Once we fix both of these in -devel, we can probably build these for F-12 and get these manually tagged (beta freeze is in effect).
Hey,
sorry for answering that late but my notebooks energy supply broke down and I'm still waiting for the new one to arrive.
Sorry to hear that! Happened to me a few months back, but luckily, a colleague has a compatible power adapter. Hope you get yours soon.
Seems like a good idea to put Boo.NAnt.Task.dll in boo-devel. However I do not understand why there's a dependency. In the spec-file itself there're only BuildRequires which shouldn't make problems. I can't make any changes at least for the next week, so feel free to fix this if you have some spare time.
Mono runtime dependencies are automatically calculated: $ ls /usr/lib/rpm/*mono* /usr/lib/rpm/mono-find-provides /usr/lib/rpm/mono-find-requires
But yes, I'm equally puzzled. As I mentioned, if mono-nunit-devel is installed during build, banshee ends up depending on mono-nunit at runtime. .NET might have solved Microsoft's DLL hell, but Mono, at least, has some quirks for us packagers in the Linux world :p
mono@lists.stg.fedoraproject.org
-
Christian Krause -
Michel Alexandre Salim -
Paul Lange