On Tue, Mar 01, 2016 at 04:26:26PM +0100, Mark Wielaard wrote:
Now that f24 has branched I thought I would start early with a
for a system wide change for f25:
This is because I never proposed a system wide change before and so
could use some help finishing the proposal. If someone could help me
fill in the missing (procedural) blanks in the above proposal that would
I did get some off-list comments that I incorporated in the proposal
- 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
- 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.