Hula -- mixed mono package

[Toshio Kuratomi]

On Tue, 2006-06-06 at 19:59 +0100, Paul wrote:
> Hi,
> 
> > > 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}. 
> 
> Which is correct. You'll find that if you run the spec, if you don't
> redefine libdir and are on a 64 bit system, then the mono stuff will
> probably end up a bit messed (I don't know the package, so it's possible
> the .pc file ends up in /usr/lib64/pkgconfig with the mono stuff also
> being there or it may all be in /usr/lib)
> 
Okay.  So the pkgconfig is in /usr/lib64/pkgconfig.  And it
references /usr/lib64/hula which is wrong.  So that will have to be
changed.  Anything else you can think of?

> > But there is one ELF program hulamonohelper that is being
> > put into /usr/lib/hula along with the mono .exe/.dll's.
> 
> That sounds very odd - is there a symlink back to bindir?
> 
Nope.  It is invoked directly from two scripts that hula installs into
%{_sbindir}.

> > 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})
> 
> I wouldn't. If everything is in /usr/lib/hula then it should all be
> happy. As Jeremy has said though libexecdir does sound sane, but it
> might not. Are you running a 64 bit system currently (I'm happy to try
> the package here) or is it available as a BZ FE review package?
> 
It sounds like at least pkg-config is not happy.  Leaving it
in /usr/lib/hula is wrong as it's potentially a 64bit binary in the
32-bit directory.

I'm running 64 bit but would be happy if you took a look as well.  hula
is an orphaned package so it's in cvs.  I've checked my changes in to
hula/devel. Just don't try to build it as it's still in flux :-)

> > 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.
> 
> They don't need to go in there. However, if you have a package which
> builds on them (for example, MonoDevelop [ 178904 ] needs boo [ 189092 ]
> amongst others), the configure script may not pick them up correctly. By
> having them all in /usr/lib, you can be assured that the package will be
> found. It's not the best way of doing things, but until things become
> saner with mono and how it's set up and how it looks for things...

So it sounds like using %{_libdir} won't affect the immediate package
but it will affect anything that tries to use it when they build.  I've
updated the wiki.  Feel free to modify it if I got it wrong.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-extras-list/attachments/20060606/df70c93f/attachment.sig>