Hi,
/usr/lib : Libraries for programming and packages /usr/share : Architecture-independent data
I think that page needs updating for /usr/lib otherwise /lib64 is pretty pointless!
/usr/lib64 is mentioned in the next section: /usr/lib<qual> : Alternate format libraries (optional)
What I mean is that it should read /usr/lib<qual> in the main part rather than in a sub-section ;)
Upstream for many many year have been saying that as mono assemblies (actual programmes such as monodevelop rather than the gmcs compiler etc) should be placed in %{_datadir} as they are not arch (or even operating system) specific.
I think Toshio made a good point here: we have to distinguish between
a) the fact whether a library or an executable is arch-dependent or not
All applications that use mono *should* be arch-independent. The libs are not arch independent.
and
b) whether, in case of arch-independence, the files should be placed in /usr/lib or /usr/share
For a) seems to be the agreement that C# assemblies are arch independent.
Yep...
Regarding b) I'm convinced that it is well within the definition of the FHS to place arch-independent libraries into /usr/lib. Sure, /usr/share must only contain arch-independent files, but this does not mean, that all arch-independent files must go into /usr/share. ;-)
I have a feeling that the reason for using /usr/lib64 was set many moons ago (just after mono was accepted into Fedora) - it seemed logical.
Regarding the use of %{_datadir}: Do you have any reference when upstream explicitly asked for that? At least their response to my question was quite clear to use the paths defined by upstream (which is /usr/lib).
Right, let's jump back into our respective TARDIS/other time machine of your choice. Ready? Wvworp Wvworp Wvworp Meeglarp Meeglarp Floobp Floobp...
Way back (something like 2001ish) when Ximian released their embrionic mono/mcs application, Miguel stated that the plan was "for now" to keep things in %(libdir) (note, this is *not* our %{_libdir} but /usr/lib) and to move things to %(datadir) (this is our %{_datadir}) at some point as all applications would be platform independent and this would make life easy for the different array of platforms out there.
ISTR a big debate on the Ximian mailing lists over this (it rattled on for ages - and I mean ages). The largest noise came from those on the just released 64 bit system. They found building mono a complete pain due to the %{_libdir) vs %(libdir) problem. This was again cited as a reason to move to %{_datadir}
Eventually out of the mists two parties did arise. Those who would use /usr/lib and those who knew what they were doing and corrected things to use %{_libdir} otherwise their 64 bit systems would get messed up beyond belief!
Those from the %{_libdir} side of things regularly submitted the corrected patches to Ximian (then Novell and now Microsoft t/a Attachmate) who pondered them and then dumped them, citing the move to %{_datadir} still being on the cards...
I've always been of the opinion with mono that upstream seriously don't know where they want to put things. In some cases the automake/conf bits point to %(libdir) macro and then in the code itself, it's hard coded to /usr/lib
AFAIK I see mostly fixes on their side changing %{_libdir} to %{prefix}/lib. So it looks like that upstream treats the usage of %{_libdir} as a bug.
Some do, some don't. It's a bug, but only in a mirror dimension.
We do it right. Eventually others will follow.
Hm, I don't believe that upstream will ever adapt to Fedora's way of packaging mono....
Their choice. Just because the world drives Ford cars doesn't make them right...
TTFN
PFJ