Build Separate Debug Symbols Package
 

I'm looking for script examples for creating a separate debugging symbol package when building a package.

The compiler options must be set (--enable-debug=full, -ggdb). Yet with that option set, traditionally slackbuild scripts strip the debugging symbols from the package like this:

Leaving those lines in the build script strips the debugging symbols despite building with the appropriate compiler options.

Commenting out those lines will build a package with debugging symbols, which creates a much larger package.

I want to build once and create two packages: the binaries and the debugging symbols.

I found this thread.

I have been trying various options based upon what I have read around the web, but no success. :(

Thanks!

You want to create 2 packages and compile one time for both or compile 2 times ?

I guess it is just a matter of copying all the slackBuild lines and paste them after the makepkg command,
then change PKG and BUILD/TAG variables, so you end with 2 packages created

Have a look at the kde.SlackBuild I made in this as it does exactly what you want.

http://wildwizard.abnormalpenguin.co...build-2.tar.xz

Thanks much wildwizard.

I more or less have massaged your script to mine. Yet there are some things I don't understand:

1. Why tar-1.13 and not the more recent tar?

2. The directories inside the package all have epoch zero time stamps rather than the current time. Why?

3. When viewing the package with Ark, the directories change ownership to that of the viewer's account rather than remain root:root. Why? When I view them as root the ownership shows root.

4. Why delete files inside the package greater than 50 bytes in size? Is this something unique to the package you are building?

Thanks much!

Segregate the debug files before doing the strip step. About root/user, it's always best to be root when you build packages.

The tar-1.13 question is a very old which I would have thought you had seen discussed before. tar-1.13 has a couple of unique behaviours which are essential to creating a proper Slackware package -no other version exhibits the desired characteristics. It works perfectly, so there is no need to worry yourself about eh old version number.

gnashly beat me to this

probably a bug

don't trust ark

EDIT: Did you get the directory timestamps from ark too?

Actually this is not deleting files inside the package it is deleting packages less than 50 bytes in size as they would not actually contain any data and are thus duds

I am root --- in a chroot. That's the mystery. :)

Reducing the script commands in a terminal showed the date stamp problem occurs at this point:

find . -type f -name *.debug | cut -b3- | xargs -r tar-1.13 cvf

I didn't like that weird behavior and I came up with this instead:

WAS:

CHANGED TO:

Seems to segregate fine. I don't have the weird date stamps and when opened in Ark the ownerships all read root regardless of who views the package contents. I still have to install and find a known bug to verify I can produce a meaningful backtrace.

Well, being root in chroot is not exactly the same situation as being root directly, because bash don't read its configuration files, I believe.

Anyway, to trick the chroot to behave like a direct login, I use

Yup, that's what I do. :)

For package creation only one characteristic matters and that is the formatting of the storage of subdirectories of '.', which can easily be simulated with more modern versions of GNU tar.

@Woodsman Here is a comparison so you can see the difference.

GNU tar 1.13:
GNU tar 1.26:
It is relatively trivial to work around this problem using tar's transform option and a regex to make modern tar save the directories in tar 1.13 format, e.g.:

GNU tar 1.26:
Alternatively, on a system with a tar more modern than 1.13 but not modern enough to have the transform option, you could pre-format the list of directories by using find and sed and then pipe this to tar instead:

As a third alternative, you could make use of cpio's ability to save in ustar (The POSIX.1 tar) format and send it the formatted list instead:

There are other methods as well but you get the idea. ;)

I have thoroughly tested these methods of tar-1.13 style directory formatting and had no issues whatsoever. Slackware's pkgtools cannot tell the difference and treat the packages created exactly the same way as files created with tar 1.13.

P.S. There is a whole thread about why tar 1.13 is used. It is long but an interesting read.

The file listing is only one of the issues and indeed that can be circumvented. But the difference in handling of symbolic links is the reason for sticking with tar-1.13. If you ever upgrade a package containing for instance a "/usr/share/man" directory then you will see what happens when upgradepkg uses plain tar instead of tar-1.13.

Eric

Sure, but I specifically italicised package "creation". ;) Installation does indeed have other issues if you were to try and take tar-1.13 out of Slackware. I wasn't suggesting or advocating that.

Edit: The summary from the thread I linked earlier was that pkgtools could in theory use a modern tar if you made certain changes. IIRC, in addition to handling the differences in formatting sub-directories of '.', installpkg's extraction would also need to be altered (i.e. to no longer use '-l' '-U' as their meanings have changed).

One of the conclusions from Patrick's comments was that he doesn't do this as it is less maintenance to stick with one version of tar that reacts exactly as his tools expect, rather than having to update them again every time the GNU tar authors decide to change (or break) something. Which seems entirely sensible, so no complaints from me.

Since pkgtools is likely to stick with tar 1.13 for the foreseeable future, when making packages I agree it is best to use makepkg where possible otherwise you have to remember to handle directory formatting accordingly (and you would also have to handle conversion of symlinks to shell script format).

P.S. As a side note, I actually occasionally use spkg (the reimplemnation of pkgtools that SalixOS uses) on other distros as a kind of secondary package manager for handling any software I build from source. I do this because it is far easier to create Slackware packages than any other common format. However, since spkg does not provide a makepkg, I knocked up a very basic makepkg, which only handles directory formatting and conversion of symlinks to shell script code, since these seem to be the only things that SlackBuild scripts typically use makepkg for these days.