FS#48902 - Better debug package output directory handling

Attached to Project: Pacman
Opened by Earnestly (Earnest) - Monday, 11 April 2016, 22:41 GMT
Last edited by Eli Schwartz (eschwartz) - Friday, 06 July 2018, 00:01 GMT
Task Type Feature Request
Category makepkg
Status Closed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version 5.0.0
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Consider adding a new variable such as DEBUGDEST which like PKGDEST allows makepkg to automatically move built debug packages to that directory.

The reasoning behind requesting this functionality in makepkg is that it already knows the pkgname, fullver, pkgarch and PKGEXT when constructing the final package in create_package() and so it knows the correct file name for the debug package when building with options=(debug strip).

This is important as naive scripts might assume something like mv "$PKGDEST"/*-debug-* "$repo-debug" which is open to false positives if any package name (although unlikely) contains *-debug-*.

With a DEBUGDEST makepkg can guarantee that only the debug packages are moved making it easier (or more reliable) to support [*-debug] repos with Usage = Sync Install Upgrade
This task depends upon

Closed by  Eli Schwartz (eschwartz)
Friday, 06 July 2018, 00:01 GMT
Reason for closing:  Not a bug
Additional comments about closing:  rejected on the mailing list as not being useful
Comment by Earnestly (Earnest) - Monday, 11 April 2016, 23:46 GMT
Here's a proof of concept patch which adds this feature.
Comment by Earnestly (Earnest) - Tuesday, 12 April 2016, 00:17 GMT
Here's a second patch which changes the way the case statement behaves. This time it will match any pkgtype that isn't of type debug as the fallback for normal packages. This prevents people from setting pkgtype in a PKGBUILD and potentially interfering with things although as PKGDEST is set before the case statement if they did so nothing would have happened.
Comment by Levente Polyak (anthraxx) - Tuesday, 12 April 2016, 00:45 GMT
patches related to pacman/makepkg should go to the public pacman-dev mailinglist for both, discussion and possible inclusion
Comment by Earnestly (Earnest) - Tuesday, 12 April 2016, 16:06 GMT
Anthraxx, I've subscribed to pacman-dev to do just this, but both yesterday and today I get the following when attempting to send to the list:

> Your message has been rejected, probably because you are not
> subscribed to the mailing list and the list's policy is to prohibit
> non-members from posting to it. If you think that your messages are
> being rejected in error, contact the mailing list owner at
> pacman-dev-owner@archlinux.org.

As a result I've posted it here and at #archlinux-pacman, if you are able to post to the list I wouldn't have any objection to people posting it on my behalf.

(Edit: Initially this was just a feature request but I had a go myself locally and this patch was the result.)
Comment by Allan McRae (Allan) - Monday, 18 April 2016, 04:31 GMT Comment by Earnestly (Earnest) - Monday, 18 April 2016, 19:32 GMT
Oh, to conclude:

The reason I couldn't reply to the mailing list is because I subscribed using a "@gmail.com" address in the UK, which awhile ago had to change its name due to copyright to "@googlemail.com" and although it's "@gmail.com" again[0] the header still refers to "@googlemail.com" and due to this mismatch the mailing list rejected my emails.

Changing my email to the "@googlemail.com" variant in the mailman configuration page allowed me to send again. Just in case anyone gets a similar. (This post is google fodder.)

0. https://gmail.googleblog.com/2010/05/google-mail-is-becoming-gmail-in-uk.html
Comment by Eli Schwartz (eschwartz) - Thursday, 05 July 2018, 23:58 GMT
EDIT: Firstly, this feature request description sucks and is terribly nondescriptive, so, fixed for future searchers.

The conclusion from the mailing list was that this was never really needed. No packages contain the pkgname string "-debug-" in the official repos, and only 9 in the AUR. Furthermore, it is simple to compare the filenames to see if they match up to a non-debug variant.

Personally I'd point out the correct way to determine the pkgname is simple:

for pkgfile in *.pkg.tar.xz; do # or however you intend to find candidates, I recommend makepkg --packagelist
pkgname=${pkgfile##*/}
pkgname=${pkgname%-*-*-x86_64.pkg.tar*}
if [[ ${pkgname} = *debug ]]; then
echo "${pkgname} is a debug package"
fi
done

This will very accurately match things which end in "-debug", but not have -debug- somewhere in the middle.

It will accidentally detect packages which are legitimately named foo-debug, but of the 12 packages in the AUR which are like that:

5 are just an "llvm-debug" split pkgbase that should probably be deleted, since users can recompile llvm itself with options=(debug)
1 is an old version of a repository package compiled with one file containing -DQT_QML_DEBUG, which should likewise be deleted and I've asked the maintainer to create a "plasmoidviewer-debugger" package.
2 are programs built with debugging tools, which are not the same as unstripped executables with extra debugging symbols... but I've asked their maintainers to rename to the more accurate "foo-debugger".
1 is the same as above, except flashplayer which is proprietary, so I didn't bother requesting anything.
3 are legitimate false positives where the program itself is called "foo-debug", for instance the "debug" extension for python-flask. All of them are "any" packages, so it doesn't matter.

...

Regardless of the reason why it doesn't matter, all of these cases can be solved for pacman 5.1 by considering the following superior heuristic: compare the pkgbase to the "foo-debug" pkgname, e.g. `bsdtar -xOf "${pkgfile}" .PKGINFO | awk -F' = ' '/^pkgbase/{print $2}'` is the pkgbase, is it equal to "${pkgname}-debug".

For pacman 5.0.x which created one debug package for each pkgname instead of one for each pkgbase, it was even easier: see if "${pkgfile/-debug/}" is also a file, if so, they are corresponding package and detached debugging symbols. (Note the bsdtar|awk check works too, for non-split packages. If the pkgbase is empty on pacman 5.0.x or identical to pkgname on pacman 5.1 then it's the base package)

Trying to set the output directory is the *wrong* technical solution to the problem, and assumes you used PKGDEST, and assumes you'll never want to take older package files, sort them, and add them to repos. Why not just do it right to begin with?

Loading...