Hi,
On 06/01/2011 08:13 AM, Paul F. Johnson wrote:
>>> The point was that hardcoding /usr/lib is always wrong. If they're arch
>>> dependent, they should be in %{_libdir}. If not, /usr/share. So we
>>
>> Why? ;-) The FHS uses the following definitions:
>>
>> /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)
> 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
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.
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. ;-)
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).
> 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.
> 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....
Best regards,
Christian
--
packaging mailing list
packaging@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/packaging
