On Fri, Sep 18, 2009 at 6:41 PM, Jeff Johnson <n3...@mac.com> wrote: > > On Sep 18, 2009, at 12:11 PM, Saravanan Shanmugham (sarvi) wrote: > > Separating the symbol files and into their own package is definitely in >> the plans. >> >> > Well, packaging detached debugging symbols (and source code so > that line numbers can be displayed) was done in RPM like 5 years > ago and is already widely deployed. > iirc the first time debuginfo was deployed was with REDHAT 9 http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/release-notes/x86/
This is the original proposal https://bugzilla.redhat.com/show_bug.cgi?id=67760 You really should look at what is implemented. > > Note that from a RPM packaging POV, the existing -debuginfo scheme > is all very feeble and hacky and horendously fragile and obscure. > I mostly agree. IIRC, it depends also by a not upstream patch to gdb and work only with the GCC compiler collection. Or perhaps also i don't have undestood it well. (aside) In your opinion I right or wrong that if a package don't have debugging symbol the rpmbuild fail if the packager don't define %define debug_package %{nil} - or use the obsure hack to exit in %install . But perhaps i digress... > > So don't take my comments as criticism, I'd *LOVE* to see a better > packaging framework for detached debugging symbols in RPM. > The question is the turnaround time between someone posting a traceback >> on the web and a backend system translating the traceback with symbols. >> >> > If end-to-end turnaround efficiency is your goal, you need to > look carefully at how traceback information can be accurately > associated with the components involved. Extracting executables/libraries > from *.rpm is just a very teensy part of a much larger problem. > > One option is to have a filesystem where all the files have been >> extracted and ready for translation. But can cost additional diskspace >> which can add up in the long run. >> >> > That's basically what is in a -debuginfo package, files under > /usr/src/debug/* include source and detached debugging symbols. > > If the RPMs are archived, the system would need to identify the RPMS >> involved in traceback, download, extract them, do the translation, then >> discard the extracted stuff. >> This could takes some time to do, specially if you have to download the >> whole RPM, and if you had to uncompress/untar each RPM in its entirity. >> >> From RPM, tar.gz or CPIO, this can be expenseive. As I understand it you >> need to unzip and untar the file, piping it to a filter to get the >> file(s) you want. >> >> XAR format maintains an index, that allows you to go to and extract a >> specific file, and the individual files are compressed, as I understand >> it, meaning the ones of interest can be extracted, which can be more >> efficient. >> >> > Again, speed or overhead of archive extraction is hardly an issue when > everything > necessary for debugging is _ALREADY_ extracted into a -debuginfo package. > > At this point, I am just trying to understand/measure that cost >> impact/tradeoff, and was looking to try these features. >> >> > Look closely at tools/debugedit.c and scripts/find-debuginfo.sh. Those > two files are what is used to automate producing -debuginfo packages. > Some ref are also here https://fedoraproject.org/wiki/Packaging/Debuginfo > > I'd suggest grabbing some -debuginfo *.rpm files and examining. This > command makes it quite easy to see what is in a -debuginfo package > > rpm -qp --yaml foo-debuginfo*.rpm > > hth > > 73 de Jeff > > Sarvi >> >> >> -----Original Message----- >> From: rpm-users-ow...@rpm5.org [mailto:rpm-users-ow...@rpm5.org] On >> Behalf Of Jeff Johnson >> Sent: Friday, September 18, 2009 5:34 AM >> To: rpm-users@rpm5.org >> Subject: Re: Attempting to compile rpm5 for RH Linux EL5 >> >> >> On Sep 18, 2009, at 2:04 AM, Saravanan Shanmugham (sarvi) wrote: >> >> Thanks. I was able to get it compiled and installed. >>> >>> I am proposing the use of RPM5 for package management internally. One >>> point of interest to me in RPM5 is the use of XAR format, and more >>> specifically the option of being able to extract specific files from >>> within the XAR archive without having to untar/extracting everything. >>> Atleast that's what the xar wiki page claims. >>> >>> >> You can extract specific files from any archive format, including >> cpio/tar/xar, rather easily. >> >> We need a way to be able to extract specific executables and libraries >>> >> >> from a specific version of the build, from its archived RPMs, on >>> demand, to help decode a crash or traceback. >>> >>> >> So you would seem to want debugging symbols. What is more commonly done >> is to split the symbols from the executable/library and put into a >> separate -debuginfo package. >> >> GDB then loads the detached symbols. >> >> So far, I haven't been able to figure out the RPM5 option or XAR >>> option that allows me to do extract a specific file or list of files. >>> >>> >> For cpio payloads it starts with >> rpm2cpio foo*.rpm | cpio -itv >> to display the files in a payload. Then one adds logic (described in >> "man cpio") to select which files you want. >> >> Is there such an option. If not how easy do you think it is to >>> implement such an option, if we can help. >>> >>> >> Each archive format has a different selection process. But rpm2cpio is >> used to seek to the start of the payload. >> >> 73 de Jeff >> ______________________________________________________________________ >> RPM Package Manager http://rpm5.org >> User Communication List rpm-users@rpm5.org >> ______________________________________________________________________ >> RPM Package Manager http://rpm5.org >> User Communication List rpm-users@rpm5.org >> > > ______________________________________________________________________ > RPM Package Manager http://rpm5.org > User Communication List rpm-users@rpm5.org >
