[mono-packagers] moonlight 2 packaging

[Andrew Jorgensen]

Hi Ismael,


We're currently trying to work through packaging issues with moonlight 2 on our side too.  I don't think we have a draft spec file yet.  Let me describe the approach we're taking so far:


There need to be two source packages (in our build system that's one project with two spec files and the same set of tarballs) one for the browser plugin and another for the desktop assemblies.


The package for the browser plugin should really just build the .xpi and the take the plugin directory (including it's assemblies, it's own libmono and libmoon, etc.) and put that where browsers will find it.  This source package needs to have a full mono source tree (the 2.6 tarball should be usable for this when it's released but for now they may require a specific revision).  That's because we build some of the the moonlight assemblies from the mono source tree (ones like System.Xml.dll which are already part of mono) and then massage them with security attributes or something during the moonlight build.  So, unfortunately, you have to build mono --with-moonlight and then build moonlight with some parameter that tells it where the mono source tree is.


The package for the desktop assemblies is much easier (except that it's broken in the most recent release and maybe still in the next).  This one only needs the moonlight source tree and is build with options to disable the plugin build.  The reason it doesn't need a mono source tree is that the desktop assemblies are just 2.0 profile builds of moonlight-specific assemblies, so assemblies like System.Xml are already built and don't need to be massaged.  This one should have a "make install" that actually works (puts the assemblies in the GAC, for instance).


You could probably do this fine with a single spec file but we don't intend to for SUSE.


Rusty Howell does both packaging and QA for moonlight now (I had to give it up when Wade Berrier left a void in mono packaging).  I have CC'd him here so he can correct me if I'm wrong on some point and so that you can work with him.  I have also included the mono-packagers list (you may want to subscribe at http://lists.ximian.com/mailman/listinfo/mono-packagers-list) so that other packagers can have an idea of what's required for this.  Moonlight is a hard build (not as hard as OpenOffice.org though, or so I'm told).


Hey, I thought Fedora had a "no moonlight" policy.?

>>> Ismael Olea  10/04/09 9:32 AM >>>

Hi:

I'm currently packaging Moonlight 1 for Fedora. Obviously I would like
to do with v2. Do you have any kind of draft spec for v2?

-- 

        A. Ismael Olea González
 
        http://olea.org/diario/
        http://aduaneros.org, la ONG sin futuro.
 
        El mundo debe empezar a tener miedo a un planeta OLEA