2009/5/23 Ismael Olea <ismael(a)olea.org>
2009/5/21 David Nielsen <gnomeuser(a)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