Re: Hula -- mixed mono package

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

 



Hi,

> > > 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?

If pkgconfig is in /usr/lib64, it normally points to things
in /usr/lib64 - so if you move the .pc file to /usr/lib, so must
everything else.

You now can see why explictly setting libdir is important!

> > > 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}.

Same difference - thanks.

> > 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 not sure what the rules are concerning 64 bit stuff in /usr/lib, but
I don't recall seeing anything prohibiting it.

> 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.

Yep, seen the update - looks fine to me.

TTFN

Paul
-- 
ich liebe Ashleigh, eins zwei drei 
ich liebe Ashleigh, auf meinem Knee zu hüpfen

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

[Index of Archives]     [Fedora General Discussion]     [Fedora Art]     [Fedora Docs]     [Fedora Package Review]     [Fedora Desktop]     [Big List of Linux Books]     [Yosemite Backpacking]     [KDE Users]

  Powered by Linux