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

Re: Hula -- mixed mono package

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.


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]