2009/5/23 Ismael Olea <ismael@olea.org>


2009/5/21 David Nielsen <gnomeuser@gmail.com>


Fedora currently is the odd man out in terms of packaging managed code as arch dependent, one of the big plans I had for the SIG was to find a way to change that and bring us more in line with what everyone else is doing including upstream.

I've started the packaging of Chronojump + nplot-gtk. I've being taking some notes in order to propose the enhance of the guidelines but I'm not the most experiencied guy for proposing them.

Could you suggest a working agenda for doing this?  Seems to me you have a clear idea of what you want to achieve.

Poke me on Monday, while my access to fedora cvs is utterly broken I can help out translating the pkg-mono work into Fedora speak. I have also been in contact with Ubuntu's directhex (Jo Shields) to help us adapt the work they did to obsolete mono 1.0 to space savings and performance increases.

I think the top issues would be debating what the road ahead for pure managed code is. Personally I sway towards making it noarch and putting it in %{_datadir} but that is somthing worth debating and seeking input from upstream and other downstream vendors on. Ideally this work would go towards making a set of downstream packaging guidelines for everyone to lean on.

I think our guidelines should handle:

pure managed code
mixed managed and unmanaged code
monodoc documentation generation
handling of debuginfo
Insertion of .dll into the GAC
Use of system libraries
obsoleting Mono 1.0 support

I ,quickly and without much thought, propose the following:

Pure managed code is noarch and goes into %{_datadir} (I believe this is similar to what python does in Fedora)

Mixed code is by definition arch (compile failures for these must be clearly commented and bugs filed with polite requests for our arch teams to help), we also need to review which Fedora supported platforms currently has Mono and craft a new ExclusiveArchs string or similar manner of handling these cases. Thanks to the nice people at IBM we now have Mono on ppc64 e.g. and everything we have packaged so far ignores this arch.

If your package has documentation it must be built and put in a separate package, the correct monodoc magic must be invoked and the correct requires applied.

debuginfo I am sketchy on, there are good reasons to keep this as part of the package since mono handles debugging differently from most code and it is only enabled when you run with the --debug switch. The only saving we get thus from splitting them out is diskspace savings, this would be important mainly for getting on the desktop livecd (where it has already been made abundently clear that we are second class citizens and generally unwelcome). I doubt this is worth the work. However Jeremy Katz has been kind enough to create a patch to make this possible, it is untested so we would need to evaluate this heavily.

Occasionally you may need to insert a library into the GAC, we need guidelines for when and how to do this correctly. For most packages this happens automatically but there are cases where we need to do it manaually and for those we need clear guidelines for packagers. Investigation is needed here, I don't yet know enough about this specific area, generally I do what pkg-mono does here as they generally have a good hold on how to wangle this beast.

I would propose that every package should delete all prepackaged .dll files prior to configuration to ensure that we are not building against bundled libraries, if this is impossible the package is not suitable for Fedora without patching.

Mono 1.0 support should be obsoleted where we can, if upstream willtake patches that is good otherwise we need to carry them. It is a significant gain in performance and a substantial saving on disk. It is well worth the effort and should be made policy. We need a guideline for how to do this for packagers.

- david