#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 , 10 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
debug
doesn'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
dbgsym
package 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 resultingdbgsym
package 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, thedbgsym
package 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 creatingdbgsym
packages 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 , 10 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 , 10 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 , 10 years ago
Attachment: | brp-strip.os2.diff added |
---|
by , 10 years ago
Attachment: | macros.diff added |
---|
comment:5 by , 10 years ago
BTW, Yuri, I also have some other questions to you:
- Why does RPM use the
__os_install_post
macro definition from the mainmacro
file rather than from the platform-specificmacros
file (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/sh
dependency come from and why do many-many packages have it in their requirements (although it's not explicitly set in their.spec
files)? Note that we don't even have such a file (there is no/bin
directory by default). - Where do you take
yacc
for building the current version ofash
RPM? It fails here and no yacc among available packages.
comment:6 by , 10 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 , 10 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 , 10 years ago
Priority: | major → blocker |
---|
comment:11 by , 9 years ago
Severity: | → low |
---|
comment:12 by , 9 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
First of all, the
.dbg
symbols are automatically created because our RPM setup specifies/usr/lib/rpm/brp-strip.os2
as the%__os_install_post
hook (executed after%insatll
). This can only be disabled by placing%define __os_install_post %{nil}
into the.spec
file which itself is not clean (because there may be other hooks attached to%__os_install_post
that 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
.spec
file 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.spec
file 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.os2
to 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).