Bug 441517
Summary: | nant includes non-nant, not-from-source libraries | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Toshio Ernie Kuratomi <a.badger> |
Component: | nant | Assignee: | Paul F. Johnson <paul> |
Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | low | Docs Contact: | |
Priority: | low | ||
Version: | rawhide | CC: | alex, gnomeuser |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | 0.85-20.fc9 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2008-04-14 15:20:20 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 435898 |
Description
Toshio Ernie Kuratomi
2008-04-08 15:24:04 UTC
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. |