I compile my package with splitdebug & installsources features for quick debugging. (Also avoid situations like recompiling the program eliminates the bug) The binary packages are really huge. Generally, debuginfo and source are much bigger than remains. I spread binary packages across my varios servers. Every time I install a package, I download a HUGE binary package (including source and debuginfo). After emerge'd, I simply rm /usr/lib/debug and /usr/src/debug to save disk space. I do love what CentOS/RHEL do on this. They split debuginfo and source out into two standalone packages. Whenever I analyse a coredump, I install them. To implement this, there's something I thought: 1. Binary packages are totally an optional feature on Gentoo. Dependencies are defined as ebuild atoms. Implementing complete split package (e.g. split vim into vim-common, vim-enhanced, vim-minimal) feature looks like building another package manager. 2. Requires binpkg-multi-instance feature, obviously. 3. When provided splitdebug and installsources feature, generate 3 binary packages. (debuginfo and source xpaks are just a tarball including files) e.g. openssl-1.0.2m-1.xpak openssl-1.0.2m-1-debuginfo.xpak openssl-1.0.2m-1-source.xpak 4. Add --install-comp parameter to emerge, defaults to --install-comp=base when binary found, --install-comp=all when compiling sources. Accept values are base,debuginfo,source,all. 5. /var/db/pkg/*/*/CONTENTS file contains full information. qcheck / equery -k ignores missing files in /usr/{lib,src}/debug . 6. Source package can be simply generated by `ebuild xxxxx prepare' if it's not built earlier.
There's a patch for debug tarballs with FEATURES=separatedebug here: https://chromium-review.googlesource.com/c/chromiumos/third_party/portage_tool/+/815663
(In reply to Xiami from comment #0) > 6. Source package can be simply generated by `ebuild xxxxx prepare' if it's > not built earlier. Sort of, but when we currently do is use debugedit --list-file to generate a list of source and header file names that get installed to /usr/src/debug. The installsources code is here: https://gitweb.gentoo.org/proj/portage.git/tree/bin/ebuild-helpers/prepstrip According to this, debuginfo rpms also contain the source code: https://fedoraproject.org/wiki/Packaging:Debuginfo?rd=Packaging/Debuginfo https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/developer_guide/intro.debuginfo It would be very easy to do like they've done, and generate packages that have a -debuginfo suffix. It would not require any changes to our binary package repository format, since these things could be treated as regular binary packages that happen to have a package name ending with -debuginfo.
We can see here how they've simply added a -debuginfo suffix to the package name, and otherwise they look like normal rpms: http://mirror.cs.princeton.edu/pub/mirrors/fedora-epel/7/x86_64/debug/Packages/a/ I've suggested that they do the same for FEATURES=separatedebug: https://chromium-review.googlesource.com/c/chromiumos/third_party/portage_tool/+/815663#message-7b5233ac7673d412eb7910125fa96a51b6453889
Note that debian also uses a package name suffix, either -dbgsym or -dbg: https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols
We should create a formal proposal for this, extending https://www.gentoo.org/glep/glep-0078.html.
(In reply to Zac Medico from comment #5) > We should create a formal proposal for this, extending > https://www.gentoo.org/glep/glep-0078.html. I'm wondering if that should be a separate GLEP. GLEP 78 tries to focus on how the archive looks from inside without actually telling anything about the filename, split builds etc.