On Mon, 2006-07-03 at 15:30 +0100, Paul Howarth wrote:
> Toshio Kuratomi wrote:
> > On Sat, 2006-07-01 at 09:46 +0100, Paul Howarth wrote:
> >> 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.
>
> Thanks for the explanation. I think it's very useful for guidelines to
> include the rationale behind them. It helps people to understand them
> and is also useful in determining whether an exception to the guidelines
> should be made, or indeed if the guidelines need updating to cover some
> case that hadn't been considered before.
>
I revised the File Locations section with the information about how the
system administrator can create AOTs after install. Hopefully it's now
clearer why we're making things arch-specific.
I'll copy this version over to the formal Packaging/ tree later today
unless there are more suggestions.
-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
