[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Fedora-packaging] New Mono Page for new guidelines

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.


Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]