On Sat, 2006-07-01 at 09:46 +0100, Paul Howarth wrote: > On Fri, 2006-06-30 at 13:28 -0700, Toshio Kuratomi wrote: > > I've reworked the Mono page to reflect the new Guidelines we confirmed > > yesterday. If people want to take a look, it's here: > > http://fedoraproject.org/wiki/PackagingDrafts/Mono > > > > Changes are color coded: Red removes, green adds, blue is a > > justification for people who didn't attend the meeting and will be > > removed from the final copy. (I probably should have done this before > > the meeting rather than after, sorry.) > > > > If no one objects, I'll replace the current Packaging/Mono page this > > weekend. > > The guidelines now say "no noarch packages". What about packages such as > lat, that are already in Extras as noarch and don't contain any > arch-specific AOTs? > The meeting log mentions that there are probably very few packages that contain pre-built AOTs (as opposed to glue-libraries which plainly go into %{_libdir}). The problem resides in the fact that the system administrator can choose to compile AOTs after installation of the package. Due to the fact that mono will only find AOTs that are in the same directory as the .dlls, the directory that the .dlls are in has to be the right one for an ELF shared object on that platform. This means /usr/lib for x86 and /usr/lib64 for x86_64. > It does, however, install an mcs-built .dll and .exe in %{_prefix}/lib. > It would need to be changed to %{_libdir} and non-noarch. The contents of the lat package may well be arch independent but doing this seems to be the least evil course to pursue WRT mono's limitations. This is also one of the issues that caused Debian to move mono from /usr/share to /usr/lib. > Is there anything technically wrong with this other than not lining up > with the guidelines? Hopefully the first paragraph explained that. If so, I'll try to merge that explanation into the guidelines. -Toshio
Attachment:
signature.asc
Description: This is a digitally signed message part
-- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
