#134 closed defect (fixed)
spec: Standardize debug package creation
| Reported by: | dmik | Owned by: | |
|---|---|---|---|
| Priority: | blocker | Milestone: | |
| Component: | rpm | Version: | |
| Severity: | low | Keywords: | |
| Cc: |
Description
There are some programs that provide debug packages (those ending with -debug). These packages are meant to contain .dbg files for each .exe and .dll` file which are the extraction of the HLL debug info from the executable.
The current scheme of creating these packages is inconsistent: on one hand it implicitly creates .dbg files for each .exe/.dll of each RPM that is built, on the other hand the package maintainer needs to manually add the respective sub-pkckage directives to the .spec file.
This needs to be sorted out and automated as much as possible.
Attachments (2)
Change History (15)
comment:2 by , 11 years ago
I wrote earlier in some of my mails:
BTW, about debug packages. We should actually define a clear policy for them. First of all, the suffix
debugdoesn't seem correct to me since it more refers to an application that is built in debug mode (-DDEBUG and so on), not debug symbols. In theory we may want to provide debug mode builds as well, so to avoid name clashes we should select a different name for symbols packages. I suggestdbgsym(I saw it's used on some other platform).
Another question is if we should make a single
dbgsympackage for all sub-packages of a given application or we should create a separate sub sub package for each non-noarch package in the .spec file. If we go the first way, then the resultingdbgsympackage must be unrelated (must not depend on any other package so that it can be installed at any time w/o the need to install everything). If we go the second way, thedbgsympackage should obviously depend on its parent sub package. I think that we may go the first way for now as it's simpler. Later, we may come up with some RPM macro that will automate this task by creatingdbgsympackages for all sub packages w/o the need to explicitly specify each of them in .spec. This will be the best solution but perhaps not for now as it's not trivial.
Now I have one more argument for going the second way (a separate dbgsym sub-sub-package for each sub-package). Imagine a situation when there are two separate sub-packages both providing the same binary, say, sh.exe. If there is a single debug package for both of them then there will be obviously no way to provide debug info for both binaries.
comment:3 by , 11 years ago
BTW, using %define __os_install_post %{nil} to disable debug symbol file creation (which you have to do if you don't provide the debug packages — otherwise rpmbuild will complain that there are some .dbg files left unpacked) has one unwanted side effect: it also disables compressing .exe and .dll with lixlite (because both emxomfstrip and lxlite are called from /usr/lib/rpm/brp-strip.os2). Actually, the lxlite step requires a configuration variable of its own (something like %__compress_binaries).
comment:4 by , 11 years ago
I had to already do some hacking to solve the above problem. Attaching the updated brp-strip.os2 and macros diffs here. With these diffs, disabling .dbg file generation is as easy as adding %define _strip_no_debuginfo 1 to the .spec file. The lxlite compression may be similarly disabled with %define _strip_no_compress 1. I tested it on dash (http://trac.netlabs.org/ports/ticket/26) and it works.
Yuri, please update the RPM packages. Note that once it's updated, we should fix all our .spec files and replace the ugly %define __os_install_post %{nil} hack with one of the above defines (or both, depends on the package need).
Also note that many packages that currently provide -debug sub-packages don't actually need them if these packages only contain .exe files: if an exe is not EXCEPTQ-enabled, having a .dbg file is pretty much useless.
by , 11 years ago
| Attachment: | brp-strip.os2.diff added |
|---|
by , 11 years ago
| Attachment: | macros.diff added |
|---|
comment:5 by , 11 years ago
BTW, Yuri, I also have some other questions to you:
- Why does RPM use the
__os_install_postmacro definition from the mainmacrofile rather than from the platform-specificmacrosfile (where it is redefined)? This is not how it should work (judging form the comments in these files). - Do you know where does the
/@unxirroot/bin/shdependency come from and why do many-many packages have it in their requirements (although it's not explicitly set in their.specfiles)? Note that we don't even have such a file (there is no/bindirectory by default). - Where do you take
yaccfor building the current version ofashRPM? It fails here and no yacc among available packages.
comment:6 by , 11 years ago
1) I don't remember... I did it in 2010...
2) rpm adds dependencies from .spec files, running script across installed files, by itself internally.
3) see #1 ;-)
comment:7 by , 11 years ago
Ok, it will be more correct to discuss this within http://trac.netlabs.org/ports/ticket/26. Moving there.
As for this issue, can you apply my diffs to the current 4.8 RPM and release it today?
comment:10 by , 11 years ago
| Priority: | major → blocker |
|---|
comment:11 by , 10 years ago
| Severity: | → low |
|---|
comment:12 by , 10 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |

First of all, the
.dbgsymbols are automatically created because our RPM setup specifies/usr/lib/rpm/brp-strip.os2as the%__os_install_posthook (executed after%insatll). This can only be disabled by placing%define __os_install_post %{nil}into the.specfile which itself is not clean (because there may be other hooks attached to%__os_install_postthat will be vanished as well by this override). This should be made configurable through a simple dedicated variable.The interesting thing is that the standard RPM macros already provide a special template that not only dynamically enables all the necessary steps (such as the ones that strip executables and extract their debug info) but also instantiates the respective sub-package directives in the
.specfile to fully automate and synchronize the debug sub-package management. This template is called%debug_package. The package maintainer is only requested to include this macro in his.specfile and everything else is done automatically (in most cases).This template however requires some additional work to make it work on OS/2. This shouldn't be a big deal. One of things that needs to be done is linking
/usr/lib/rpm/brp-strip.os2to it (instead of unconditionally doing so in%__os_install_post). Another thing is that we need to decide which naming scheme to use for the debug packages. (See the next comment).