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
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
