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
--
Vertraue mir, ich weiss, was ich mache...
--
packaging mailing list
packaging@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/packaging
