fedora-extras-list@redhat.com
[Top] [All Lists]

Re: Hula -- mixed mono package

Subject: Re: Hula -- mixed mono package
From: Toshio Kuratomi
Date: Tue, 06 Jun 2006 11:07:22 -0700
On Tue, 2006-06-06 at 18:41 +0100, Paul wrote:
> Hi,
> 
> > I'm working on updating the hula spec to the latest version and found
> > that some of the programs within hula now depend on mono.  The install
> > currently puts the mono packages in /usr/lib/hula and the normal
> > binaries and libs into %{_libdir} which appears to be the expected
> > outcome.  However, it has a helper application hulamonohelper that drops
> > privileges from the server before invoking the mono applications.  This
> > is installed in /usr/lib/hula rather than %{_libdir}/hula or
> > %{_libexecdir}/hula.  Should I change this or is it actually an
> > allowable practice for mono apps?
> 
> Add to the top of the spec
> 
> %define _libdir %{_exec_prefix}/lib
> 
> compile and be happy - mono is a strange beast, accept where it goes and
> when you use rpmlint, you can ignore quite a lot of the errors as
> rpmlint doesn't understand mono and it's packaging.
> 
That won't work.  This is a mixed package.  Some mono .exe/.dll's and
some ELF libs/programs.

The upstream hula install seems to be doing the right thing by putting
mono .exe/.dll's into /usr/lib/hula and the ELF .so libs into
%{_libdir}. But there is one ELF program hulamonohelper that is being
put into /usr/lib/hula along with the mono .exe/.dll's.

My question is whether I should try to move that program around to a
different location since it's going to be a 64bit binary on an x86_64.
(Hmmm... and on Fedora it should probably go to %{_libexecdir} rather
than %{_libdir})

Also -- a bit more explanation of why mono apps need to go in /usr/lib
is in order b/c the Core packages tomboy and beagle end up
in /usr/lib64/ on an x86_64.

-Toshio
-- 
fedora-extras-list mailing list
fedora-extras-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-extras-list
<Prev in Thread] Current Thread [Next in Thread>