Hey all,We discovered that a few mono packages had issues with including prebuilt binaries so I did a quick check of all the mono packages I could find to see just how big the problem is. I used the mono-detect.sh script I'm attaching to find mono using packages. It might not be a complete list as I was unable to find one package that everything depended on. (It really seems like everything should depend on mono(System) or mono-core but they don't) If someone can come up with a better check and make sure I found all the packages that would be appreciated.
I then downloaded the tarballs for each of the packages and ran find . '*.dll' to find prebuilt binaries. Where prebuilt binaries existed, I looked to see if there was discernable source files. If I found none, then I marked the package as binary in the attached mono-pkgs list. If I found source the package was marked as unknown since someone has to check if the files are rebuilt or included verbatim.
I also looked for packages which appeared to bundle third party library source. This is the equivalent of linking against static libraries in the C world so we want to fix these at some point as well. They are marked 'bundled' in the mono-pkgs file.
What to do about these problems? It has been proposed that the programs which contain binaries be blocked from going into F9 until the problems have been resolved. This plan would still have to address what to do with the "unknowns" on the list.
I'm also thinking of drafting a packaging guideline to delete all prebuilt binaries from the spec file. This would make it quite plain when a package is built from source and when it is not as opposed to having to decipher whether timestamps have forced a rebuild. I think this should be fine for any package already in Fedora (and not blocked by the binary requirement). Some packages may need to be bootstrapped in initially, though, so I'll have to think of some way to deal with that.
-Toshio PS: spot has a patch for db4o so that's one down :-)
status can be clear, bundled, binary, or unknown * binary implies bundled * binary must be yanked * bundled needs to be fixed * unknown means you have to read the notes to know what's going on. Note that the maintainers of the packages marked clear should still perform their own audit of the code as I may not have caught every imported library. status | package ----------+------------ clear | avahi binary | banshee_ bundled | beagle_ clear | bless unknown | boo_ clear | cdcollect bundled | cowbell_ binary | db4o_ clear | dbus-sharp clear | evolution-sharp bundled | f-spot_ clear | gbrainy clear | gecko-sharp2 clear | gmime clear | gnome-do clear | gnome-sharp clear | graphviz clear | gsf-sharp clear | gtk-sharp clear | gtk-sharp2 clear | gtksourceview-sharp clear | ice_ binary | ikvm_ clear | ipod-sharp unknown | log4net_ unknown | mono_ clear | mono-addins unknown | mono-basic_ unknown | mono-debugger_ unknown | monodevelop_ bundled | monodoc_ clear | monosim clear | mono-zeroconf bundled | muine_ binary | nant_ clear | ndesk-dbus clear | ndesk-dbus-glib clear | podsleuth clear | themonospot bundled | tomboy_ clear | xsp .. _banshee: Boo.dll files are in an Extras/Boo directory. May be able to disable at buildtime. Note in spec that Boo does not build on ppc .. _beagle: At least, TagLib-sharp, Snowball.Net and Lucene.Net. Possibly others. .. _boo: Ships with prebuilt Boo dlls. Package wouldn't build so I couldn't check if those get rebuilt or not. It would be great if packages that have prebuilt .dlls would rm -f the .dlls in the spec file so we can check this easily. .. _cowbell: taglib (different from TagLib-Sharp.): Note, taglib's upstream may be dead and there might not be any other packages using this. Pending verification of that, maybe it should be a subpackage of cowbell. .. _db4o: At least Cecil.FlowAnalysis, Mono.Cecil, Mono.GetOptions (mono-core) .. _f-spot: At least, dbus-sharp, libgphoto2-sharp, gnome-keyring-sharp, Tao, google-sharp, FlickrNet, semweb, (dbus-sharp-glib?), Mono.Cairo, Mono.Addins .. _ice: Ice is a little strange as it has several source tarballs and several subpackages for different languages. .. _ikvm: lib/IKVM.GNU.Classpath.dll, IKVM.AWT.WinForms.dll, IKVM.Runtime.dll .exe's as well. Looks like there's either no source or source only for the .exe's. .. _log4net: This has some .dlls. It looks like they are removed and rebuilt during the build. But we should really rm all dlls in the spec file as otherwise you have to trust that what the build says is happening is actually happening. .. _mono: ships several binaries. Unknown whether these are rebuilt. Someone please look into it. mcs.exe mscorlib.dll System.dll System.Xml.dll Also, if these were used for bootstrapping, they should be removed in the spec as we should be able to build from source with the mono package itself. .. _mono-basic: Has some dlls that look like they are just used in testing. Has another dll that says it is for bootstrap. Similar to mono bootstrap, this should not be necessary once the package is in Fedora. .. _mono-debugger: Has a prebuilt dll in a build directory. unkown if this is rebuilt. .. _monodevelop: Prebuilt nunit.core.dll nunit.framework.dll. Appears to have source. Have not checked if they are rebuilt. Definitely has bundled libraries. At least, Mono.Cecil and NUnit. .. _monodoc: Bundles at least Lucene.Net .. _muine: At least, dbus-sharp and dbus-sharp-glib .. _nant: https://bugzilla.redhat.com/show_bug.cgi?id=441517 .. _tomboy: At least Mono.Addins
Attachment:
mono-detect.sh
Description: application/shellscript
Attachment:
signature.asc
Description: OpenPGP digital signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list