Tom "spot" Callaway wrote:
> On Tue, 2008-09-16 at 13:36 +0100, Paul wrote:
>> he rational
>> behind this is that .NET CIL is a non-architecture specific system
>> which
>> calls on a central repository of dlls held within GAC. It is a shared
>> resource rather than a platform specific resource. It is also not a
>> traditional library (.so).
>
> Except that those files seem to be architecture specific...which is why
> we moved them to %{_libdir} in the first place.
>
When researching this for the Guidelines, I found a thread on the Debian
lists in which they decided to move from /usr/share to /usr/lib because
of input from Miguel. I can find that discussion in their archives if
needed but the gist of it was:
1) DLLs can call architecture specific code using architecture specific
types and there's no good way to detect that the code is doing this
without analyzing the source code. We don't want to inflict that on
packagers. If there is an easily automated method for finding these
cases, that would help here.
2) DLLs can be AOT-compiled. Those AOT-compiled bits have to live next
to the architecture independent DLLs. If the AOT loading code was
rewritten to be able to find the DLLs in a different place from the AOT
compiled code or if the AOT compiled bits could have all the information
necessary and not need to find the DLLs at all, then that would make
this go away.
If someone's going to allocate resources to fixing these issues, make
sure I dig up that Debian thread as there may be a third problem I'm not
remembering at the moment.
-Toshio
Attachment:
signature.asc
Description: OpenPGP digital signature
-- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
