Build a new subpackage named XFree86-libs-debug containing an additional set of libs built for debugging. Need to investigate if it is more beneficial to do this in addition to the XFree86-libs package, or just build the main libs with debug info in them always. That will help make up for the lack of .debuginfo packages, which are next to impossible to generate for XFree86 while still allowing me to debug the X server and it's modules. Whenever gdb can debug the X server properly, I can investigate .debuginfo instead.
Having debuggable libraries available with the shipped OS is definitely an advantage. There are 2 main ways we could do this. The first, is to implement what is requested above. The second method, is to make debuginfo packages just for the libraries. The third method is to split the libraries out into separate subpackages, which include their own debuginfo packages. #1 is probably the easiest to implement, and I believe is relatively easily doable by tweaking host.def during compilation and getting Imake to spit out an extra set of debuggable libraries, which could be installed separately from a new subpackage. This is an X specific debuggable library hack though, and is a bit ugly, while it is probably the easiest solution to implement and would nonetheless provide the needed functionality. #2 is much more difficult to implement since it is complicated to produce debuginfo subpackages in the XFree86 and xorg-x11 packaging because we can't use rpm's default stripping behaviour. In order to implement debuginfo for X, we would have to replicate the rpm scripts which implement debuginfo *inside* the X build process. That alone isn't complex for one OS release, but since this changes every OS release, we'd need to implement it separately for every single OS release we wish to have xorg-x11 buildable on, which is a total nightmare (I've tried to do this). #3 is the ultimate solution. By using modularized and autotooled libraries, they can be built normally and use standard/stock rpm stripping behaviour. Only the X server and it's modules are affected negatively by rpm's default stripping behaviour, which is why there are no .debuginfo rpms for X currently. The perfect solution (#3) requires that we first are using a modular build of X, in which some or all of the libraries are built from their own rpms. While this is a wanted feature, it is not yet integrated into Fedora Core, and while some of the libraries are available modular, most of them are canonical in monolithic form and wouldn't be available outside of the Imake built monolithic tree for the forseeable future. So realistically, solution #3 wont be available until at least X.Org 6.9.0 minimum, perhaps longer. Solution #2 is a huge mess to even consider attempting, unless it can be done inside the Imake framework cleanly and submitted as patches to upstream X.Org, to minimize maintenance headaches. Solution #1 is the easiest to implement, but the least modern and clean compared to the niceness of the debuginfo packages. Nonetheless, I think this is still the best solution for us to consider for now. Summary: We should consider doing solution #1 for Fedora Core 3, or alternatively deferring this issue until Fedora Core 4 development, at which time we should re-explore the above 3 options and any other possibilities which might arise. Comments/feedback appreciated.
Flagging bug as FC4Target, setting to ASSIGNED state.
I've investigated this and have concluded that the effort is not worth the time. Once we have modularized X11R7 in the tree, we'll have debuginfo packages for free for everything except perhaps the X server and driver modules, but perhaps even for them using the dlloader. Adding this feature to the packaging at this point would only benefit Fedora Core 4, and would require additional conditionalization complications in the xorg spec file, which seems hardly worth the effort. Removing from trackers, and setting status to "WONTFIX".