[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