Re: F25 feature Parallel Installable Debuginfo packages

On Tue, Mar 01, 2016 at 04:26:26PM +0100, Mark Wielaard wrote: I did get some off-list comments that I incorporated in the proposal page: - Some people thought .gnu_debuglink really should go away since it is a somewhat broken standard. You need to do a full CRC check to be sure you got the correct file, which is fairly expensive. But I don't want that because I am not 100% sure a "pure build-id" solution is really supported by all tools that possibly use separate debug files. - Since one of the goals is to pull in /usr/lib/debug and /usr/src/debug from a network server where the debuginfo packages have been installed there is a problem if the build-id file /usr/lib/debug/.build-id/xx/yyyy which is a symlink to the main ELF file remains there. Even if we move it to the main package. This means we do have to move it somewhere else (maybe /usr/lib/.build-id?). Unfortunately this would mean consumers that rely on that location have to be changed. Which was one of the things I hoped to avoid. I'll audit the various debuginfo using programs and discuss upstream if we can agree on a new standard location. We can work around it by keeping the symlink in the debuginfo file and point it at the new location. - I didn't describe, and hadn't thought about, what a simple dnf upgrade would do when there are parallel installed versions of the same debuginfo package was installed. My idea was that users would only install/update debuginfo packages through the dnf debuginfo-install plugin, which would get a flag for how to deal with parallel installed debuginfo packages. Some input/feedback about the default way of how dnf upgrade should/shouldn't handle debuginfo packages would be appreciated. - This feature doesn't explicitly need a mass rebuild, but obviously a package can only have parallel installable debuginfo package once it has been rebuild. We might need/want some indicator that can be used to give the user good feedback when it isn't possible. This is already a problem at the moment for some packages when you try to install the debuginfo package for the 32 and 64 bit version. (it might just succeed, but rmp file coloring will make it so that some of the 64 bit files silently overwrite the 32 bit files). Since nobody yelled and screamed the idea was completely bogus and nobody publicly replied to this list discussion I hope I can take the lack of dissent as silent assent. But please do let me know if there are issues that I overlooked or if this isn't the correct way to start working on a system wide feature. I'll file some bug reports against packages/upstream and start working on patches as outlined in the Detailed description. Cheers, Mark