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: > > > > > > 1. Native code in the same rpms as the bytecode. > > > 2. 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).
