| « the FUBAR is killing me | GuideXMLification » |
in the works
I've been working on a little project for Gentoo. I'm keeping it under wraps at the moment, since if I never get to an actual release I don't want to dash anyone's (misplaced?) hopes. Unfortunately, the only release by upstream is an RPM -- and one that gives the FHS the finger (whoever heard of /usr/appname/? bah. It's worse than /usr/kde/). Adapting it to an ebuild is proving to be a big PITA, especially for someone who's new to writing ebuilds (me). The best part is that this would normally work slightly better on x86, which it's designed for, but I'm developing and testing on amd64. It actually runs perfectly; requires a few emul-linux-x86-* libs as it's 32bit, but it does run.
Unfortunately, I have yet to find a way to make rpm.eclass work with the rest of Portage so that it installs to /opt/ properly. More precisely, it should be installed to /opt/, as specified in the devmanual, since it's a binary package. However, the dang thing expects to find its shared libraries in /usr/lib/, which is bad 1) because even x86 binary packages still must have everything placed in /opt/, and 2) because /usr/lib/ is no good on amd64, because it should be /usr/lib32/. And no, I won't/can't resort to any symlinking kludge from /opt/ to /usr/; that wouldn't fly too well with other developers.
However, since the source code is not released, I can't think of a way to make the app look for its .so in something besides /usr/lib/. More headaches: I've been trying to submit a support request at upstream's website, but keep running into rather convenient 500 Internal Error messages. I'll send another request and a phone call or two on Monday, once the Thanksgiving craziness is more settled down. tsunam has been a help in figuring out a few things, too. Thanks! 
I'm really excited about this package. I want to get it working according to Gentoo standards. It works just fine when all the stuff is dropped as-is into /usr/lib32 (don't ask me why), but /usr/lib and /opt/ cause the dreaded "cannot load shared object" error. ldd shows nothing out of the ordinary, not that it would be fixable if it did. I hope upstream listens to my request; this app is something that I really want to bring to the Gentoo community. I may have to find a proxy maintainer, since I don't have commit access to the right part of the tree, but I do want it to be in Portage.
And, I want to be my first "real" successful ebuild.
* * *
Speaking of Thanksgiving, I cooked quite the feast yesterday. (Rant: I'm never doing a turkey again, even though it turned out to be delicious, especially since it was my first time roasting one.) Yay for my first Thanksgiving as a married man. All the cooking seemed to go over very well with my wife and the rest of the family. 'Twas fun; I should do really big, complicated dinners more often.
Trackback address for this post
Trackback URL (right click and copy shortcut/link location)
4 comments
ahh, thanks Donnie. now i have to learn more about how i can actually make it work with said LDPATH. :p
yay for #gentoo-dev-help! and, of course, our wonderful devmanual. :)
Don't consider the devmanual as the definitive word on where things go. That simply isn't true. Sometimes, the right thing to do is to put stuff where upstream expects it. Users switching to Gentoo from other platforms appreciate it - because the app is where they expect it.
I don't know the app (what's with all the secrecy? That's not the Gentoo way!), but if it was me, I'd be most likely to get it working in /usr/<appname> first, before even considering moving it to /opt. It's easier to move something that works than to try and get something working in the first place.
Best regards,
Stu
Thanks for the tip; I'll check out the NX stuff. Wrapper scripts seem like more of a pain than any other solution, but I'll investigate everything I come across.
In this case though, since it is a purely binary distribution, it should be placed in /opt/. This greatly simplifies things for both x86 and amd64; no need to specify installdirs based on arch.
And it works fine, just fine, especially if I drop the proper stuff in /opt and call it with LD_LIBRARY_PATH="/opt/foo" command.sh; it properly picks up the stuff. Actually, regarding /usr/appname, the weird thing is that in the RPM, it specifies files in /usr/bin/, /usr/share/, /usr/lib/, and /usr/appname/. The executables are located in both /usr/bin/ and /usr/appname/. It's seriously messed up; should just be /usr/lib/ and /usr/bin/, with the license/documentation in /usr/share/. That is, if it behaved properly. It needs to all go in /opt/ anyway.
Regarding the secrecy, well...maybe I just want to be the first one to offer it to the community. As soon as I can figure out a solution to the env/library loading/installdir issue, then I'll open a bug for it and provide some installation docs on my devspace. :)
Because if none of this works out, then I don't want too many folks besides myself to have wasted their time on it. I figure that at the least, the time I spend learning about Portage and ebuilds and how to work around more complicated installation issues is time well spent, even if this particular project ends up failing.
Comment feed for this post