As I look into lifting the hold on Mono packages in Fedora Extras (aka, blessing the mono packaging guidelines found here: http://fedoraproject.org/wiki/Packaging/Mono), I'd like to state my opinions on the following blocker issues: 1. Redefining libdir for mono packages: If mono and its tools cannot find a library on a 64bit architecture when it lives in %{_libdir} (/usr/lib64), then mono is fundamentally broken on that architecture, and needs to be fixed. This is a serious flaw, and I will not have us doing ugly hacks in spec files to work around mono's ineptitude. Every other core component is able to handle this, this bug should be filed and fixed. 2. Putting DLLs in %{_datadir} vs %{_libdir}: The FHS says that /usr/share (aka, %{_datadir}) is for "Architecture Independent Data". These DLL files do not seem to qualify as "Architecture Independent Data". I think that having them live in the: %{_libdir}/mono/ hierarchy seems to be the most appropriate for them at this point in time. Obviously, this can be revisited if upstream changes the default location. The gacutil command should be putting these DLL files in the right place. 3. Forcing local copies of DLL libraries instead of using system installed DLLs. This concept is documented upstream here: http://www.mono-project.com/Assemblies_and_the_GAC#Libraries_with_Unstable_APIs IMHO, this is a really stupid and braindead idea. In fact, I've yet to talk to anyone who actually thinks this is a good idea. This is the same thing as static linking a private copy of a library instead of using the system shared lib. We do NOT permit this sort of behavior in Fedora, and mono is no exception. I've copied alexl on this email, since he is the mono owner in Fedora Core, and likely has an opinion or two. ;) ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! -- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
