The variable should be used when the file is pre-stripped by upstream, not when the build system/install system strips it before getting to Portage. Doing so hinders debug altogether. Please fix this properly.
Same explanation as #332067: /usr/lib/icecat/icecat is a copy of xulrunner-stub, installed and already stripped by portage when you built xulrunner.
... but it doesnt explain why icecat needs to copy it in the first place
... and you should be properly documenting your ebuilds with bug references
(In reply to comment #2) > ... but it doesnt explain why icecat needs to copy it in the first place That's the way xulrunner works. Because icecat exists as a file in /usr/lib/icecat, it reads the rest of the files it needs from /usr/lib/icecat. Make it a symlink, and it won't run, trying to read the files from /usr/lib/xulrunner-1.9.2. (In reply to comment #3) > ... and you should be properly documenting your ebuilds with bug references There's no bug to reference because there's simply no bug, but I do agree a comment would be helpful.
so fix icecat to work with symlinks ? seems like an oversight on the part of icecat as symlinks are nice. as for bug references, you could just refer to the one with documentation as to why it exists at all. like this bug.
(In reply to comment #5) > so fix icecat to work with symlinks ? seems like an oversight on the part of > icecat as symlinks are nice. Thing is, /usr/bin/icecat is already a symlink to /usr/lib/icecat/icecat, which would in turn be a symlink to /usr/lib/xulrunner-1.9.2/xulrunner-stub. That can't work, there simply isn't a way for xulrunner to figure out where icecat's files are stored in that case. The alternative is to make /usr/bin/icecat a wrapper script for /usr/lib/icecat/icecat, but that's a symlink now, and symlinks are nice :) BTW, icecat is just a modified version of firefox, and firefox has the same problem. Adjusted summary accordingly. > as for bug references, you could just refer to the one with documentation as to > why it exists at all. like this bug. I was about to suggest RDEPEND="${RDEPEND} java? ( >=virtual/jre-1.4 )" +# This is a copy of a file installed and already stripped from another package: +# net-libs/xulrunner. QA_PRESTRIPPED="usr/$(get_libdir)/${PN}/${PN}" linguas() { but this bug # can be included. Jory, does that look okay to you?
i'm obviously not familiar with xulrunner, but i guess a wrapper shell script wouldnt work either ? #!/bin/sh exec /path/to/xulrunner-stub "$@" what exactly does it need ? an argv[0] pointing to the right place ? there are utils that can do that sort of thing.
If you (In reply to comment #7) > i'm obviously not familiar with xulrunner, but i guess a wrapper shell script > wouldnt work either ? > #!/bin/sh > exec /path/to/xulrunner-stub "$@" Nope. > what exactly does it need ? an argv[0] pointing to the right place ? there > are utils that can do that sort of thing. It needs to be able to find argv[0], and since it has to resolve symlinks to handle the current /usr/bin/icecat -> /usr/lib/icecat/icecat situation, the /usr/lib/icecat/icecat it ends up with must be a file. This works for me (amd64, so as /usr/lib64/icecat/icecat): #!/usr/bin/perl exec { '/usr/lib64/xulrunner-1.9.2/xulrunner-stub' } '/usr/lib64/icecat/icecat', @ARGV; So it should work just as well with a compiled launcher program. But to be honest, I'm not seeing the benefit over the current situation. The launcher program already exists: that's what xulrunner-stub does.
To clarify the above: xulrunner-stub is a small launcher program that checks to see where it's called from, sets up xulrunner to look in that directory, and then loads xulrunner. It doesn't really do anything beyond that, so it wouldn't get you all that much to move some part out of it.
45KiB to screw with argv[0] sounds pretty stupid, but at any rate ... i'd add to the ebuild comment about what xulrunner-stub is and why it needs to be copied, and/or simply link to this bug as your comment #8 & comment #9 sound sufficient to me. QA_PRESTRIPPED="usr/$(get_libdir)/${PN}/${PN}" #332071#8
Short comment with a reference to this bug added.
