[Rpm-maint] [PATCH] RFC: Add build-id links to rpm for all ELF.

Lubos Kardos lkardos at redhat.com
Thu Jun 2 12:36:23 UTC 2016


Hi,

I skimmed through your patches and they seem ok to me from a coding style point
of view. I would suggest just cosmetic changes like replacing asprintf() with
rasprintf() and on some places 8 spaces are used instead of tab
for indentation.

The problem with patches is that they move some logic from the debugedit
tool to rpm which is something I and Florian don't like.

Lubos

----- Original Message -----
> From: "Mark Wielaard" <mjw at redhat.com>
> To: rpm-maint at lists.rpm.org
> Sent: Thursday, May 26, 2016 5:00:58 PM
> Subject: Re: [Rpm-maint] [PATCH] RFC: Add build-id links to rpm for all ELF.
> 
> Hi all,
> 
> On Wed, 2016-04-13 at 20:59 +0200, Mark Wielaard wrote:
> > This is an RFC patch to move the main ELF file build-id symlinks
> > from the debuginfo package into the main package and to use a
> > different base directory for the main ELF file build-id symlink.
> > Use /usr/lib/.build-id instead of /usr/lib/debug/.build-id
> > 
> > There are two reasons for doing this. The main package and the
> > debuginfo package might get out of sync, or the debuginfo package
> > might not be installed at all. In which case finding the main ELF
> > file through the build-id symlink becomes impossible. Secondly by
> > moving the main ELF build-id symlink in its own directory the
> > /usr/lib/debug directory gets populated with only debuginfo files
> > which is convenient if the user might want to have that directory
> > populated through a network mountpoint.
> > 
> > This patch is still a work in progress. It seems to work, but might
> > not be the best way to implement the above idea. The idea itself
> > might not be perfect (comments more than welcome). I tried to
> > follow the rpm coding style as much as I understood it. Please let
> > me know if I use some wrong constructs, or if there are alternate
> > ways to do what I am doing. It contains one testcase, that is fairly
> > minimal. I'll add more if we agree on the semantics of the idea
> > (help writing better testcases also very welcome). It obviously will
> > need some config setting (pointers to examples that use configs
> > for this kind of rpmbuild settings would be appreciated). And it
> > needs corresponding adjustments to scripts/find-debuginfo.sh,
> > including, when enabled, a backwards compatible link from the old
> > /usr/lib/debug/.build-id/xx/yyy -> /usr/lib/.build-id/xx/yyy
> > 
> > Comments, ideas and suggestions how to move a change like this
> > forward more than welcome.
> 
> I am integrating this patch with the patches I posted that integrate the
> debuginfo package handling from fedora and the new testcases and wanted
> to make the behavior configurable so a distro can setup a macro to
> define what they want. Does the following make sense?
> 
> # Defines how and if build_id links are generated for ELF files.
> # The following settings are supported:
> #
> # - none
> #   No build_id links are generated.
> #
> # - debug
> #   build_id links are generated only when the __debug_package global is
> #   defined. This will generate build_id links in the -debuginfo package
> #   for both the main file as /usr/lib/debug/.build-id/xx/yyy and for
> #   the .debug file as /usr/lib/debug/.build-id/xx/yyy.debug.
> #   This is the old style build_id links as generated by the original
> #   find-debuginfo.sh script.
> #
> # - separate
> #   build_id links are generate for all binary packages. If this is a
> #   main package (the __debug_package global isn't set) then the
> #   build_id link is generated as /usr/lib/.build-id/xx/yyy. If this is
> #   a -debuginfo package (the __debug_package global is set) then the
> #   build_id link is generated as /usr/lib/debug/.build-id/xx/yyy.
> #
> # - compat
> #   Same as for "separate" but if the __debug_package global is set then
> #   the -debuginfo package will have a compatibility link for the main
> #   ELF /usr/lib/debug/.build-id/xx/yyy -> /usr/lib/.build-id/xx/yyy
> %_build_id_links compat
> 
> Let me know if this makes sense and I will implement it and write some
> testcases for the different settings.
> 
> Thanks,
> 
> Mark
> _______________________________________________
> Rpm-maint mailing list
> Rpm-maint at lists.rpm.org
> http://lists.rpm.org/mailman/listinfo/rpm-maint
> 


More information about the Rpm-maint mailing list