|
Bugzilla – Full Text Bug Listing |
| Summary: | conflict of log4net and monodevelop | ||
|---|---|---|---|
| Product: | [openSUSE] SUSE Linux 10.1 | Reporter: | Andreas Jaeger <aj> |
| Component: | GNOME | Assignee: | E-mail List <bnc-team-mono> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | ||
| Version: | Beta 1 | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | Other | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
Andreas Jaeger
2006-01-22 15:42:28 UTC
Lluis, What's your take on this? Could the following file be deleted from the monodevelop package? /usr/lib/monodevelop/bin/log4net.dll The log4net package installs log4net in the gac... And they both provide (from an rpm standpoint) mono(log4net) = 1.2.9.0 The file can't be deleted, but MonoDevelop's rpm should not provide mono(log4net), since it's being used in MD as a private library. This could be tough... the rpm provides are generated automatically based on the dlls in the rpm filelist. (Using /usr/bin/mono-findprovides). I'm not sure if it's possible to explicitly remove one provide... ? Would MonoDevelop work if log4net was removed from the MD package and the package depended on the log4net rpm? Nope, that's not an option. MD has private copy of the log4net assembly just to avoid that dependency. MD and any other Mono application needs to be able to use private assemblies. Lluis is correct. This is a failure in whatever beast mono-find-provides is (I do not know where the file lives, I can not find it on my machine). But mono-find-provides (or whatever tool we are using) should not be looking for anything outside the GAC I'm testing a change to mono-find-provides (mono/scripts/mono-fnid-provides.in) to only scan files that have /gac/ in the pathname. Upon trying to upgrade the rpms on my rc3 box, it's failing on not being able to find mono(mscorlib). This assembly is not in the gac. Should it be? For testing, I manually put: mono(mscorlib) = 1.0.5000.0 mono(mscorlib) = 2.0.0.0 in the provides for mono-core and was able to complete the install. I have all the mono apps I know of installed (ifolder, beagle, MD, f-spot, CASA, banshee). So we can either manually provide those entries (and hope they don't change too often) or put mscorlib in the gac. I've committed the changes to mono-find-provides. (HEAD and 1.1.13.x branch). This will get fixed on next 1.1.13.x branch autobuild submission (and the above mscorlib provides will need to be added to the mono-core spec file). AJ, if you want this in CODE10, let me know. This breaks in combination with mono-find-requires on Mandriva, see http://bugzilla.ximian.com/show_bug.cgi?id=78897 An example is Mandriva's beagle package: [goetz@n5 i586]$ rpm -qpl beagle-evolution-0.2.7-4mdv2007.0.i586.rpm /usr/lib/beagle/Backends/EvolutionBackends.dll /usr/lib/beagle/Backends/EvolutionBackends.dll.mdb /usr/share/doc/beagle-evolution-0.2.7 /usr/share/doc/beagle-evolution-0.2.7/README [goetz@n5 i586]$ rpm -qp --requires beagle-evolution-0.2.7-4mdv2007.0.i586.rpm |fgrep mono mono(Beagle) = 0.0.0.0 mono(BeagleDaemonLib) = 1.9.0.0 mono(evolution-sharp) = 2.0.0.0 mono(gconf-sharp) = 2.8.0.0 mono(glib-sharp) = 2.8.0.0 mono(gmime-sharp) = 2.2.0.0 mono(Mono.Posix) = 1.0.5000.0 mono(mscorlib) = 1.0.5000.0 mono(System) = 1.0.5000.0 mono(System.Xml) = 1.0.5000.0 mono(Util) = 0.0.0.0 mono(Util) and mono(Beagle) should be provided by the beagle main package, but as Util.dll and Beagle.dll are not in gac, this deps aren't provided. I had to fix this by hand in the spec file of beagle. This is a very good point, and because of this very reason, this changed was reverted from mono before suse 10.1 shipped... In cases like these, I don't see any problems with having multiple rpms provides generated by private assemblies. I'll revert this change. |