Opened 10 years ago

Closed 9 years ago

Last modified 9 years ago

#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)

brp-strip.os2.diff (1.1 KB ) - added by dmik 10 years ago.
macros.diff (529 bytes ) - added by dmik 10 years ago.

Download all attachments as: .zip

Change History (15)

comment:1 by dmik, 10 years ago

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).

Last edited 10 years ago by dmik (previous) (diff)

comment:2 by dmik, 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 suggest dbgsym (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 resulting dbgsym 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, the dbgsym 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 creating dbgsym 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 dmik, 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 dmik, 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 dmik, 10 years ago

Attachment: brp-strip.os2.diff added

by dmik, 10 years ago

Attachment: macros.diff added

comment:5 by dmik, 10 years ago

BTW, Yuri, I also have some other questions to you:

  1. Why does RPM use the __os_install_post macro definition from the main macro file rather than from the platform-specific macros file (where it is redefined)? This is not how it should work (judging form the comments in these files).
  2. 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).
  3. Where do you take yacc for building the current version of ash RPM? It fails here and no yacc among available packages.
Last edited 10 years ago by dmik (previous) (diff)

comment:6 by Yuri Dario, 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 dmik, 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:8 by dmik, 10 years ago

Form 1. I created a separate ticket — #135.

comment:9 by dmik, 10 years ago

Created #137 for problem 2.

comment:10 by Silvan Scherrer, 10 years ago

Priority: majorblocker

comment:11 by Yuri Dario, 9 years ago

Severity: low

rpm: standardize debug package creation. fixes ticket#134.
Sending branches/rpm-4.8.1/macros.in
Sending branches/rpm-4.8.1/scripts/brp-strip.os2
Sending trunk/macros.in
Sending trunk/scripts/brp-strip.os2
Committed revision r581.

comment:12 by Yuri Dario, 9 years ago

Resolution: fixed
Status: newclosed

comment:13 by dmik, 9 years ago

JFYI, I tested the new release with this and #135 fix included and it seems to work.

However, the main target of this ticket is still not reached and I created #149 for it.

Note: See TracTickets for help on using tickets.