99% of the way done. Working: - the ports infrastructure itself should be 100% finished. When DEBUG_PACKAGES is set, an extra "generation step" occurs during make package, any package mentionned in DEBUG_PACKAGES that's not arch-independent (PKG_ARCH != *) will get a "companion" debug package. Files are generated based on packing-list information (all files with debug info are annotated as @bin/@lib/@sh) through build-debug-info(1). This creates -> a Makefile -> dynamic packing-lists with just debug files The "Makefile" part means it can be rerun several times and won't extract debug info again. The dynamic plist part means those don't go thru register-plist(1) which allow changes to the infrastructure to proceed as needed.
The debug info part is mostly Paul's work. The infrastructure emits a warning if it finds a file WITHOUT actual debug-info (which generally means a bit of work beyond "having -g and not doing strip" is needed). There is some shennanigans in build-debug-info in case some files are hardlinks, due to the way gnu-debug-link works. It's probably possible to mix the names enough to confuse build-debug-info, but I don't see this happening by accident. - the debug packages themselves hold mostly the same conflict and dependency information as the packages they are shadowing, thus they can be installed under the same conditions, and will be updated at the same time. They have a "phantom" pkgpath in the debug/* namespace. The pkg_* tools part is about 99% of the way there. - there is an env variable DEBUG_PKG_CACHE that can point to a directory. If that variable is set, debug packages will be retrieved (but not installed) along with normal package installation/updates. This can be used to debug things after the fact, even when you're 10 snapshots behind, and the debug info no longer matches. *IT IS HIGHLY RECOMMENDED THAT DEVELOPERS SET THAT ENV VARIABLE* unless they never ever intend to debug anything in ports. - there is an (undocumented yet) -d option to pkg_add that's supposed to install debug packages along normal packages. The part that's missing: - code in pkg_delete to handle -a and debug packages nicely. Currently, a debug package depends on the package proper, thus a normal package can't be deleted while its debug package is there. BUT all debug packages installed automatically are marked as "automatically installed", thus will go away with pkg_delete -a, even when the corresponding package stays around. I do need to be able to tie those things tighter. - the code in Update.pm that deals with -d is not complete. There are a few code paths which don't work, and so you may not have a debug package when you think you do. That needs to be fixed and I need to write tests. (I probably want to clean Update.pm up a bit... Once this is done, -d will get documented. I'm also wondering about an option to install all available debug packages for a given port (e.g., the debug package for the port, and the debug packages for the dependencies as well). That's not written yet. Might be convenient. Probably -dd The main part that's missing is... more debug packages. Not everything needs debug packages, probably, but most of the fundational libraries in ports (especially audio/graphics/video stuff) SHOULD have debug packages.
