On Friday 16 September 2005 12:52, Andrew Haley wrote:
Vadim Nasardinov writes:
On Friday 16 September 2005 07:24, Gary Benson wrote:
a brief summary:
- Native code in the same rpms as the bytecode.
- Native code in separate rpms to the bytecode.
...
Method 2, which is what you're proposing, has the following drawbacks over Method 1:
...
- The native package would not have access to the sources, and would not be able to generate a useful debuginfo package. This would render the packages undebuggable with gdb.
Can you elaborate? I thought native compilation worked by taking .class files as input. Where do the sources come in?
You don't debug bytecode: you debug source. Debuginfo contains source.
The part I didn't understand was how specifically Method 2 would prevent you from generating appropriate debuginfo packages. I think the source of my confusion was that I misintepreted Gary's definition of "Method 2". I was thinking along the lines of David Walluck's long-standing proposal (I hope I'm not putting words in his mouth) to share exact same .spec files between Fedora and JPackage but have native-compilation-related spec logic conditionalized.
I am a little fuzzy on why sharing exact same .spec files (modulo minor distro-specific patches) is infeasible.
Even with Gary's definition of Method 2 (call it M2), it's not clear to me why debuginfo packages are impossible to generate. (I think M2 amounts effectively to having two SRPMs for the same application).