View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0015668CMakeCPackpublic2015-07-29 04:262016-06-10 14:31
ReporterEgor Shokhin 
Assigned ToDomen Vrankar 
PrioritynormalSeverityfeatureReproducibilityalways
StatusclosedResolutionmoved 
PlatformOSLinuxOS Version
Product VersionCMake 3.2.3 
Target VersionFixed in Version 
Summary0015668: Create debuginfo package
DescriptionCPack allows us to create rpm-packages through CPackRPM module, but there is no chance to ask him for building correspondent debuginfo rpm package.
TagsNo tags attached.
Attached Filespatch file icon Added-to-fix-for-create-debuginfo-package.patch [^] (4,548 bytes) 2015-10-13 04:40 [Show Content]

 Relationships

  Notes
(0039184)
Sebastian Krämer (reporter)
2015-07-29 09:17

+1
(0039186)
Egor Shokhin (reporter)
2015-07-29 09:36
edited on: 2015-07-29 09:36

It is enough to use the instruction %debug_package in spec-file debuginfo package creation.
After adding the instruction in spec-file template - two files are created, but with the same name. One of them is the one we need.
The problem, in my opinion, is in %define _rpmfilename.
There are a couple of ways to fix the problem:
1) Change %define _rpmfilename by adding a %%{name} with some suffix
2) Remove completely %define and to add use of rpm_rebuild to change file names
The disadvantage of the first method is that many projects use constant value CPACK_RPM_... that is assigned to _rpmfilename. A second method is a kind of hacking.

(0039216)
Evgeny Kalishenko (reporter)
2015-08-03 02:33

+1
(0039217)
Domen Vrankar (developer)
2015-08-03 06:04

CPackRPM generates one rpm package at a time.

What would be the advantage of using 'debug_package' rpm macro compared to generating a new package that contains debug info files created by 'objcopy --only-keep-debug ...'?

If there is no special advantage with 'debug_package' then I would go with something like:
CPACK_RPM_WITH_DEBUG_INFO and CPACK_RPM_<component>_WITH_DEBUG_INFO
This would create an additional debuginfo package and hide away objcopy code but at the same time would be reusable for creating debian debug info packages (or by some other packaging generator that can be used on Linux).
(0039326)
Egor Shokhin (reporter)
2015-08-25 06:03

Can you check this fix, please?
https://github.com/egorsh0/CMake/commit/832d1dc41960247481453738cfe8ba0bfc331b69 [^]
(0039331)
Domen Vrankar (developer)
2015-08-26 12:30

Thanks for working on this.

I've tested the patch and generated debug package desn't contain any files (tested with 'rpm -qpl').

This was the same result that I got with my testing and if I understood the documentation correctly you have to provide file that contains list of all files that should be packaged in debuginfo package - if that's really the case then I still don't understand what the real benefit of rpm macro generated package compared to my proposal is.

I might be doing something wrong so could you please provide me with a simple test?
(0039420)
Egor Shokhin (reporter)
2015-09-14 11:48

Hello.
I fixed some mistakes, which were in program code, simplified it a bit and added description.
You've suggested to use one of two ways: to generate debuginfo package using a variable or 'objcopy —only-keep-debug ...'. Honestly, yet I've studied out the method, which we have in this moment, but I don't quite realize using objcopy.
I've tested generating debuginfo package using ordinary CMakeList with minimum parameters (name, version and so on), and taken a simple HelloWorld as code.
What can you advise or suggest me?

https://github.com/REC-SPb-ETU/CMake/commit/279837b976e2f62a6b52658db4c882cf97007824 [^]
(0040561)
Yuval Hager (reporter)
2016-02-26 14:01

+1

I'm also interested in this.

Is there anything I can help with to move this along? If this last patch is not the direction you'd like it to go, I can work on an 'objcopy' patch instead. I'm not familiar (yet) with cmake's codebase, so any pointers would be helpful.

Thanks
(0040571)
Domen Vrankar (developer)
2016-02-28 17:37
edited on: 2016-02-28 17:37

Back when the patch was proposed my issue with it was that it's relying on a rpm macro that seems to be broken on some Ubuntu distributions. Since then I've come across some other issues with rpm on Ubuntu. So since Ubuntu mostly uses deb packages and there are other issues there and since the patch seems to work on rpm based distros (Fedora, Centos) I'll review it once more and apply it if I find nothing wrong with it rpm based distros.

Patch that would work around the issues on Ubuntu would be better but I'm not too familiar with the contents of debug package so I'm not certain if they can be created with objcopy (that was more of a question on my part). If you have a more detailed knowledge regarding that, then I'd prefer such a patch since it would work the same across different distros and could possibly also be reused for CPackDEB.

(0040572)
Evgeny Kalishenko (reporter)
2016-02-29 01:30

Now Egor Shohin (Reporter) finishes the development of debuginfo feature using the standard way of generation while building src.rpm package without explicit objcopy (https://github.com/REC-SPb-ETU/CMake/tree/debuginfo [^]). We try to reduce complexity of the previous decision and use the fact, that if src.rpm generated correctly using rpmbuild then debuginfo comes with it without extra efforts.
(0040573)
Domen Vrankar (developer)
2016-02-29 02:48

As I said I'll review that patch once again and if it's OK for Linux distros using rpm packages out of the box I'll apply it.

However the last time that I've tested it with rpm development package installed on Debian based distros it did not work (different packages produced with the same version of rpmbuild) and rpm macros are quite annoying since you can't query if they are supported in certain version or not plus each distro/user can modify them as they please and if a macro fails you just get a broken package. That is why I was hoping for a solution that wouldn't rely on it.
(0042814)
Kitware Robot (administrator)
2016-06-10 14:29

Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.

 Issue History
Date Modified Username Field Change
2015-07-29 04:26 Egor Shokhin New Issue
2015-07-29 09:17 Sebastian Krämer Note Added: 0039184
2015-07-29 09:36 Egor Shokhin Note Added: 0039186
2015-07-29 09:36 Egor Shokhin Note Edited: 0039186
2015-07-30 05:57 Domen Vrankar Assigned To => Domen Vrankar
2015-07-30 05:57 Domen Vrankar Status new => assigned
2015-08-03 02:33 Evgeny Kalishenko Note Added: 0039216
2015-08-03 06:04 Domen Vrankar Note Added: 0039217
2015-08-25 06:03 Egor Shokhin Note Added: 0039326
2015-08-26 12:30 Domen Vrankar Note Added: 0039331
2015-09-14 11:48 Egor Shokhin Note Added: 0039420
2015-10-13 04:40 Egor Shokhin File Added: Added-to-fix-for-create-debuginfo-package.patch
2016-02-26 14:01 Yuval Hager Note Added: 0040561
2016-02-28 17:37 Domen Vrankar Note Added: 0040571
2016-02-28 17:37 Domen Vrankar Note Edited: 0040571
2016-02-29 01:30 Evgeny Kalishenko Note Added: 0040572
2016-02-29 02:48 Domen Vrankar Note Added: 0040573
2016-06-10 14:29 Kitware Robot Note Added: 0042814
2016-06-10 14:29 Kitware Robot Status assigned => resolved
2016-06-10 14:29 Kitware Robot Resolution open => moved
2016-06-10 14:31 Kitware Robot Status resolved => closed


Copyright © 2000 - 2018 MantisBT Team