Mono Package audit

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux