Changes between Version 1 and Version 2 of Ticket #134, comment 1
- Timestamp:
- Mar 31, 2015, 7:30:38 PM (9 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #134, comment 1
v1 v2 1 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.1 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. 2 2 3 3 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).
