FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 04-10-2008, 02:08 AM
Toshio Kuratomi
 
Default Mono Package audit

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
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 04-10-2008, 05:09 AM
"David Nielsen"
 
Default Mono Package audit

I'll just comment on the ones I own:




.. _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
Actually Nant does not build on ppc (well 0.86-beta 1 does but look what happened when we tried that), no Nant means no ppc for Boo. Regardless when Banshee 1.0 can be rolled out this should not be an issue anymore as one of the goals as been to remove all those bundled wonders. I am inclined to think the best option is waiting and letting the problem solve itself upstream. Upstream is very friendly and on a mission to destroy these anyways.



.. _beagle: At least, TagLib-sharp, Snowball.Net and Lucene.Net. *Possibly

* * * * * *others.
Beagle can compile against system taglib-sharp at least but the taglib-sharp package has been in review since forever. Again upstream is very friendly and can likely be convinced to work on the rest


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 04-10-2008, 07:28 AM
"Mary Ellen Foster"
 
Default Mono Package audit

On 10/04/2008, Toshio Kuratomi <a.badger@gmail.com> wrote:
> clear | ice_
[ ... ]
> .. _ice: Ice is a little strange as it has several source tarballs and
> several
> subpackages for different languages.

Since it's "clear" I guess there's no issue -- *whew*! But in case
anyone is curious, ice is distributed object middleware with bindings
for a number of languages including C#, so that's why the package is a
bit strange.

MEF (ice maintainer)

--
Mary Ellen Foster -- http://homepages.inf.ed.ac.uk/mef/
Informatik 6: Robotics and Embedded Systems, Technische Universität München
and ICCS, School of Informatics, University of Edinburgh

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 04-10-2008, 08:01 AM
"Nicolas Mailhot"
 
Default Mono Package audit

Le Jeu 10 avril 2008 04:08, Toshio Kuratomi a écrit :

> I'm also thinking of drafting a packaging guideline to delete all
> prebuilt binaries from the spec file.

Despite all the noise about java packaging being bad and "needing" to
be beaten into shape by FPC, this is a rule jpp self-applied years
ago.

--
Nicolas Mailhot

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 04-10-2008, 08:16 AM
Patrice Dumas
 
Default Mono Package audit

On Thu, Apr 10, 2008 at 10:01:35AM +0200, Nicolas Mailhot wrote:
>
> Le Jeu 10 avril 2008 04:08, Toshio Kuratomi a écrit :
>
> > I'm also thinking of drafting a packaging guideline to delete all
> > prebuilt binaries from the spec file.
>
> Despite all the noise about java packaging being bad and "needing" to
> be beaten into shape by FPC, this is a rule jpp self-applied years
> ago.

It is in the fedora guidelines:
http://fedoraproject.org/wiki/Packaging/Guidelines#head-c23c2cd3782be842dc7ab40c35199c07cfbfe347

--
Pat

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 04-10-2008, 08:40 AM
Konrad Meyer
 
Default Mono Package audit

Quoth Patrice Dumas:
> On Thu, Apr 10, 2008 at 10:01:35AM +0200, Nicolas Mailhot wrote:
> >
> > Le Jeu 10 avril 2008 04:08, Toshio Kuratomi a écrit :
> >
> > > I'm also thinking of drafting a packaging guideline to delete all
> > > prebuilt binaries from the spec file.
> >
> > Despite all the noise about java packaging being bad and "needing" to
> > be beaten into shape by FPC, this is a rule jpp self-applied years
> > ago.
>
> It is in the fedora guidelines:
>
http://fedoraproject.org/wiki/Packaging/Guidelines#head-c23c2cd3782be842dc7ab40c35199c07cfbfe347
>
> --
> Pat

Nicolas, unless I'm mistaken, means that jpp packages delete binary files
during the %prep stage, rather than just ignoring them during the %install
stage.

Regards,
--
Conrad Meyer <konrad@tylerc.org>
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 04-10-2008, 08:44 AM
"Xavier Lamien"
 
Default Mono Package audit

.. _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.
They should .
*

*Definitely has

* * * * * * * * bundled libraries. *At least, Mono.Cecil and NUnit.

.. _monodoc: Bundles at least Lucene.Net


working on these packages.

*



--

fedora-devel-list mailing list

fedora-devel-list@redhat.com

https://www.redhat.com/mailman/listinfo/fedora-devel-list


--
Xavier.t Lamien
--

http://fedoraproject.org/wiki/XavierLamien
GPG-Key ID: F3903DEB
Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 04-10-2008, 10:45 AM
"Nicolas Mailhot"
 
Default Mono Package audit

Le Jeu 10 avril 2008 10:40, Konrad Meyer a écrit :

> Nicolas, unless I'm mistaken, means that jpp packages delete binary
> files
> during the %prep stage, rather than just ignoring them during the
> %install stage.

Yes, that's the only safe way to do it. If you still have binary blobs
on-disk at the %build stage, there is always the risk some part of
upstream's build system will use them without you noticing.

--
Nicolas Mailhot

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 04-10-2008, 11:41 AM
Patrice Dumas
 
Default Mono Package audit

On Thu, Apr 10, 2008 at 12:45:50PM +0200, Nicolas Mailhot wrote:
>
> Yes, that's the only safe way to do it. If you still have binary blobs
> on-disk at the %build stage, there is always the risk some part of
> upstream's build system will use them without you noticing.

Indeed. And also to avoid using in-source system libraries I find it
beeter to delete them in %prep too, when possible.

--
Pat

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 04-10-2008, 01:41 PM
Toshio Kuratomi
 
Default Mono Package audit

Nicolas Mailhot wrote:

Le Jeu 10 avril 2008 10:40, Konrad Meyer a écrit :


Nicolas, unless I'm mistaken, means that jpp packages delete binary
files
during the %prep stage, rather than just ignoring them during the
%install stage.


Yes, that's the only safe way to do it. If you still have binary blobs
on-disk at the %build stage, there is always the risk some part of
upstream's build system will use them without you noticing.


Agreed. Great work JPackage guys!

Talking with Jeremy on IRC last night, he suggested we add a script to
enhance rpmbuild's %setup (post-F9) that delete's prebuilt binaries
based on file's output. That way it's an automatic thing that happens
rather than something reviewers and maintainers have to notice and add
to their spec files. (This would be overridable in spec like debuginfo
generation and provides/requires is.)


Does this sound good to you? Will it conflict with the JPackage way of
deleting things? (I don't think rm -f will issue an error if the file
does not exist so using rm -f BINARY should let JPackage guidelines
coexist with an enhanced rpm.)


I wrote up the idea here but I don't know whether it will go through the
FPC for approval, FESCo, or just be implemented in rpm:


http://fedoraproject.org/wiki/PackagingDrafts/PrebuiltBinaryCheck

-Toshio

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 

Thread Tools




All times are GMT. The time now is 06:50 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org