Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 639376 - sys-apps/portage: Separate program, debuginfo and source into 3 files when building binary package (like deb or rpm)
Summary: sys-apps/portage: Separate program, debuginfo and source into 3 files when bu...
Status: CONFIRMED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: .tbz2 support (show other bugs)
Hardware: All Linux
: Normal enhancement with 1 vote (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-12-01 11:02 UTC by Xiami
Modified: 2021-03-22 03:09 UTC (History)
4 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Xiami 2017-12-01 11:02:53 UTC
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.
Comment 1 Zac Medico gentoo-dev 2017-12-07 22:18:43 UTC
There's a patch for debug tarballs with FEATURES=separatedebug here:

https://chromium-review.googlesource.com/c/chromiumos/third_party/portage_tool/+/815663
Comment 2 Zac Medico gentoo-dev 2017-12-08 10:39:12 UTC
(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.
Comment 3 Zac Medico gentoo-dev 2017-12-08 11:15:55 UTC
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
Comment 4 Zac Medico gentoo-dev 2017-12-08 19:13:44 UTC
Note that debian also uses a package name suffix, either -dbgsym or -dbg:

https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols
Comment 5 Zac Medico gentoo-dev 2019-12-10 03:11:55 UTC
We should create a formal proposal for this, extending https://www.gentoo.org/glep/glep-0078.html.
Comment 6 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2020-06-19 20:18:56 UTC
(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.