Description of problem: nant includes several libraries that do not belong to the nant package and are not built from source. These libraries should not be shipped with the nant package. Version-Release number of selected component (if applicable): nant-0:0.86-5.fc9.i386 nant for other releases (f8, etc) has not been checked. How reproducible: Everytime Steps to Reproduce: This problem was discovered by running the following repoquery: 1. sudo repoquery --repoid=development --whatprovides 'mono(ICSharpCode.SharpZipLib)' Actual results: mono-core-0:1.2.5.1-3.fc8.i386 nant-0:0.86-5.fc9.i386 mono-core-0:1.9-3.fc9.i386 Expected results: mono-core-0:1.2.5.1-3.fc8.i386 mono-core-0:1.9-3.fc9.i386 Additional info: This problem leads to banshee, f-spot, and other desktop apps depending on nant. It looks like the entire nant-0.85/lib/ directory in the source tree (%{_libdir}/NAnt/bin/lib on the filesystem) might be upstream libraries that need to be stripped out. It also looks like we might need to do some further packaging of upstream libraries to replace some of the things in that directory.
CC'ing Alex Lancaster because we were discussing this on IRC.
We downgraded to 0.85 because of issues with 0.86 (e.g. boo didn't build against it), can you check if these problems are still in this build? http://koji.fedoraproject.org/koji/buildinfo?buildID=41174 I'm not really the package maintainer and don't know much about mono packaging, I was simply trying to repair the broken dep of boo in rawhide. I say that we get things fixed to at least how they are on F-8 and then worry about fixing this issue.
Actually the build is: http://koji.fedoraproject.org/koji/buildinfo?buildID=45460 Looking at: http://koji.fedoraproject.org/koji/rpminfo?rpmID=524072 it seems it still provides: mono(ICSharpCode.SharpCvsLib) = 0.36.4902.7334 mono(ICSharpCode.SharpCvsLib.Console) = 0.36.4902.7334 mono(ICSharpCode.SharpZipLib) = 0.84.0.0 but so does the version in F-7/F-8: http://koji.fedoraproject.org/koji/rpminfo?rpmID=47700
Ugh. If I'm looking at the cvs history right, this has never been right. This package should never have passed review. :-( This is a potential security risk since we're using many libraries which will stay at the same version even if a security hole is found. This is exacerbated since we also seem to be stuck on an older version of nant because of the boo and other rebuild problems. So even if upstream nant is proactive about fixing problems with the included libraries we're still in trouble because we aren't ready to upgrade to it.
Nant predates the review process and still has not undergone the merge review so far as I know. However we will be happy to recieve one and a patch for this.
I think this is serious and it needs to be fixed soon, but it shouldn't block the current nant/boo update. Because: 1. it isn't any worse that the nant that is currently tagged f9-final; (i.e. it's not introducing any new bogus provides) and, 2. it fixes the boo broken dep So in summary I think this problem shouldn't hold back tagging these packages for inclusion in f9-final.
The review was here:: https://bugzilla.redhat.com/show_bug.cgi?id=193957 This feels dangerous to me since it touches a build tool and a compromised build tool has the potential to compromise build tools for the rest of time. (There's a classic ACM article on this by Ken Thompson FWIW, I agree that it's not a regression. So if the danger of having the non-built from source library is great enough to block the update, it's also great enough to remove nant from the download repos (and anything that Requires it.) I'm working on a list of problematic libraries in nant now.
= Not in Fedora = mono/1.0/NDoc.ExtendedUI.dll mono/1.0/NDoc.Core.dll mono/1.0/NDoc.Documenter.Msdn.dll mono/2.0/NDoc.ExtendedUI.dll mono/2.0/NDoc.Core.dll mono/2.0/NDoc.Documenter.Msdn.dll net/1.1/NDoc.Core.dll net/1.1/NDoc.Documenter.Msdn.dll net/1.0/NDoc.ExtendedUI.dll net/1.1/NDoc.ExtendedUI.dll net/1.0/NDoc.Core.dll net/1.0/NDoc.Documenter.Msdn.dll net/2.0/NDoc.ExtendedUI.dll net/2.0/NDoc.Core.dll net/2.0/NDoc.Documenter.Msdn.dll I'm guessing these come from here: http://ndoc.sourceforge.net/ scvs.exe ICSharpCode.SharpCvsLib.Console.dll ICSharpCode.SharpCvsLib.dll I'm guessing these come from here: http://sourceforge.net/projects/sharpcvslib NUnitCore.dll This is associated with NUnit somehow but I'm not sure why it isn't being built by our package. = mono-nunit = mono/1.0/nunit.util.dll mono/2.0/nunit.util.dll net/1.1/nunit.util.dll net/1.0/nunit.util.dll net/2.0/nunit.util.dll && monodevelop? -- probably a problem in monodevelop as well. mono/1.0/nunit.framework.dll mono/1.0/nunit.core.dll mono/2.0/nunit.framework.dll mono/2.0/nunit.core.dll net/1.1/nunit.framework.dll net/1.1/nunit.core.dll net/1.0/nunit.framework.dll net/1.0/nunit.core.dll net/2.0/nunit.framework.dll net/2.0/nunit.core.dll = log4net = log4net.dll = mono-core = ICSharpCode.SharpZipLib.dll
So to fix this 100% we need at least two new mono packages in Fedora. Getting rid of the false dependencies ought to be possible by selectively removing the .dlls that are already in other packages (although I don't know whether nant will need patching to build against the system libraries or not.)
I am already getting the "I don't want to maintain nant ever" feeling at the mention of such a patch. Upstream is veery infrequently active it seems to me, and I thus doubt such a patch would be accepted.. carrying it and rediffing for every release seems far more dangerous than having some static libraries. We can manage the latter but adding a maintainer burden like this would severely limit the amount of people interested in keeping nant running on Fedora from far to few, to none at all. I would consult upstream first before taking the machete to the Nant source tree.
If that's the case, then nant needs to go. nant is doing the following things wrong: 1) Shipping precompiled binaries. 1a) Those binaries don't even have source in the upstream tarball 2) Duplicating libraries shipped by different upstreams These things have to be fixed. There is probably some leeway to fix #2 in the future but fixing #1 really needs to happen ASAP. If upstream is not active, then the problems that can arise with #2 are exacerbated. (ie: if a security problem crops up with a library shipped with nant then there's no upstream to catch the problem or fix it, only the distro maintainer.)
Fixed now with spot's latest build, and tagged f9-final: http://koji.fedoraproject.org/koji/buildinfo?buildID=46066 Closing bug.