On Wed, 2017-01-11 at 09:38 -0500, Neal Gompa wrote: > > These changes will make all files in any debuginfo file unique so they > > don't conflict when installed in parallel. There should be no changes > > necessary to programs (gdb, perf, valgrind, systemtap, > > systemd-coredump, eu-stack, abrt-hook-ccpp, etc.) that use build-ids > > or .gnu_debuglink to lookup DWARF debug information and source > > references for tracing, profiling and debugging. > > > > It would be good to tweak dnf debuginfo-install to know about parallel > > installable debuginfo packages and maybe have an easy option to > > install the debuginfo for a core file or for the packages running in a > > container. > > This also necessitates that we split sources out into a debugsource > subpackage, and ideally this should be able to be optionally disabled, > as downstream package builders may not want sources included for > debugging purposes (I've seen complaints from people about being > forced to disable debuginfo generation entirely because there's no way > to disable including sources). I believe the SUSE guys have already > done both of these things, and it would be worth it to talk to the > SUSE guys about their approach and pull it in to this. Yes. I am looking at integrating that idea into upstream rpm. But I wanted to split that proposal from this one which "simply" enables parallel installable debuginfo. I originally proposed this change for F25 but it took too much time to get all patches accepted upstream before the deadline. I am trying to avoid growing this specific change proposal and risk missing the deadline again. Shall we work on a separate change proposal (on top of this one) that introduces debugsource and debuginfo subpackages? I think that could still make it for F26. But it would be good to do it as a separate step/proposal IMHO. Thanks, Mark _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
