On 04/26/2013 03:39 AM, Stanislav Ochotnicky wrote:
Quoting Andrew Haley (2013-04-26 11:11:41)
On 04/22/2013 11:01 PM, Orion Poplawski wrote:
The eclipse PTP project that I package is starting to ship an executable in one of its plugins. The executable is packed into a jar file. This prevents debuginfo creation for the executable.
I started taking a look at how this might be handled elsewhere and found:
/usr/lib64/eclipse/dropins/cdt/eclipse/plugins/org.eclipse.cdt.core.linux.x86_64_5.2.0.201302132326.jar: 13327 Defl:X 3624 73% 02-13-2013 23:21 326488c7 os/linux/x86_64/libpty.so 23720 Defl:X 7151 70% 02-13-2013 23:21 c26c2c94 os/linux/x86_64/libspawner.so
but no debuginfo package.
Thoughts, comments?
This is pretty obviously a breach of packaging guidelines. We shouldn't be hiding DSOs in archives.
Hmm, I am not aware of any guideline touching this topic (perhaps because it's not that common). But from practical perspective these jars are extremely practical because they don't have to deal with JNI file locations and similar things which ten to be quite variable.
I don't consider this approach hiding, but we could surely improve the tooling support for it.
WRT original question, I am not sure how to proceed. Even if you generate debuginfo packages I have to wonder how easy will it be to use in a debugger?
The workaround that I am employing for the moment in PTP is to install a copy of the binary in %{_libdir}/ptp so that rpm can find it an generate debuginfo. As for how useful that might be, I don't know. I *think* gdb matches things up via hashes these days so it might work, and might for the cdt shared libraries as well.
Whatever the solution, I think we need to improve our tooling to check inside of archives for binaries. I'm CC'ing the packaging list as well.
Orion Poplawski wrote:
Whatever the solution, I think we need to improve our tooling to check inside of archives for binaries. I'm CC'ing the packaging list as well.
Please keep in mind that jarfiles get repackaged inside other jarfiles (.war, .ear etc), and I've also seen applications that built the files with .zip extensions (though I haven't touched Java packaging for some time now). To be sure you've got everything you can't rely on file extensions, you have to open every file in the RPM (and every file in every zipfile you find in there, ad infinitum) and look for the zipfile magic code. It's also best not to rely on finding the solibs in any specific place, because the chances are there's yet another .*ar format you haven't heard of that puts them somewhere else ;)
Cheers, Gary
packaging@lists.fedoraproject.org