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
