Some package review feedback (bindir vs libexecdir, docs and find-debuginfo.sh naming)

Some package review feedback (bindir vs libexecdir, docs and find-debuginfo.sh naming)

[Mark Wielaard]

Hi,

Even though we aren't yet at debugedit 1.0 I did request a package
review for debugedit in Fedora to see what other issues would pop up.

You can find the review here:
https://bugzilla.redhat.com/show_bug.cgi?id=1953633

There are two issues I think should really be resolved upstream and not
be specific to how Fedora happens to do things.

First there is the question whether to name find-debuginfo.sh without
the .sh extension. So the script would be named "find-debuginfo". This
is also https://sourceware.org/bugzilla/show_bug.cgi?id=27640

I don't mind renaming the script to find-debuginfo, but then it
wouldn't be a drop-in replacement anymore for rpm. Is that an issue?

The second issue was whether to install the executables under
/usr/libexec/debugedit (or under /usr/lib/debugedit) instead of in the
normal bindir. The rational given for that was that there is no
documentation and because "normal users" would not use the executables
directly (they might only be called by other programs (which is what
libexec is for).

To fix the documentation issue I submitted patches to make sure
everything has at least a man page. I think these programs might be
used as is by normal users. Although find-debuginfo.sh needs to stop
depending on RPM_environment variables. So IMHO bindir is the more
natural place to install them.

For a 1.0 release we should make sure the documentation patches are
there. And fix the RPM_environment variables issue: 
https://sourceware.org/bugzilla/show_bug.cgi?id=27637

Please let me know what you think of the above issues and whether there
are any other issues that you think should be resolved before we do a
1.0 release.

Thanks,

Mark

Re: Some package review feedback (bindir vs libexecdir, docs and find-debuginfo.sh naming)

[Mark Wielaard]

Hi,

On Fri, 2021-04-30 at 14:33 +0200, Mark Wielaard wrote:
> To fix the documentation issue I submitted patches to make sure
> everything has at least a man page. I think these programs might be
> used as is by normal users. Although find-debuginfo.sh needs to stop
> depending on RPM_environment variables. So IMHO bindir is the more
> natural place to install them.
> 
> For a 1.0 release we should make sure the documentation patches are
> there. And fix the RPM_environment variables issue: 
> https://sourceware.org/bugzilla/show_bug.cgi?id=27637
> 
> Please let me know what you think of the above issues and whether there
> are any other issues that you think should be resolved before we do a
> 1.0 release.

Meanwhile I did a 0.2 pre-release which contains the new documentation
and various fixes. If you are testing distro packaging issues please
try this one and report on anything that you feel should be addressed
besides the above bug for the 1.0 release.

Thanks,

Mark

$ git shortlog debugedit-0.1..debugedit-0.2 
Dmitry V. Levin (4):
  debugedit: fix exit status in case of wrong number of arguments
  tests: fix for toolchains producing compressed debug sections
  debugedit: strip extra newline characters from diagnostic messages
  debugedit: consistently use error() instead of fprintf(stderr)

Ivan A. Melnikov (1):
  debugedit: add MIPS support

Mark Wielaard (10):
  tests: Check gcc accepts -gdwarf-5 otherwise skip DWARF5 tests
  tests: Check gcc accepts -gz=none before usage
  tests: Use CC, CFLAGS, LD and LDFLAGS to create testcases
  debugedit: Add manual using help2man
  sepdebugcrcfix: Add --version, --help and man page.
  find-debuginfo.sh: Add --help, --version and man page.
  automake: Add std-options to check --version and --help work as intended.
  Makefile.am: Add scripts/find-debuginfo.sh to EXTRA_DIST
  Makefile.am: Don't try to recursively make binaries to run help2man
  Set version to 0.2 and add upload-release.sh script.

Martin Liška (1):
  Add --dwz-single-file-mode argument for find-debuginfo.sh.

Vitaly Chikunov (1):
  debugedit: Fix 'Unhandled relocation 0 in .debug_info section' on e2k

Re: Some package review feedback (bindir vs libexecdir, docs and find-debuginfo.sh naming)

[Panu Matilainen]

Sorry I missed this initially, been rather hectic times for me...

On 4/30/21 3:33 PM, Mark Wielaard wrote:
> Hi,
> 
> Even though we aren't yet at debugedit 1.0 I did request a package
> review for debugedit in Fedora to see what other issues would pop up.
> 
> You can find the review here:
> https://bugzilla.redhat.com/show_bug.cgi?id=1953633
> 
> There are two issues I think should really be resolved upstream and not
> be specific to how Fedora happens to do things.
> 
> First there is the question whether to name find-debuginfo.sh without
> the .sh extension. So the script would be named "find-debuginfo". This
> is also https://sourceware.org/bugzilla/show_bug.cgi?id=27640
> 
> I don't mind renaming the script to find-debuginfo, but then it
> wouldn't be a drop-in replacement anymore for rpm. Is that an issue?
> 
> The second issue was whether to install the executables under
> /usr/libexec/debugedit (or under /usr/lib/debugedit) instead of in the
> normal bindir. The rational given for that was that there is no
> documentation and because "normal users" would not use the executables
> directly (they might only be called by other programs (which is what
> libexec is for).

As I've said before, I personally wouldn't put this stuff into bindir, 
but then I'm not running this project :)

find-debuginfo.sh is the only thing rpm directly uses and there's 
exactly one place calling it, settable from a macro, so the exact path 
and naming doesn't matter a whole lot.

However there seem to be quite some specs referring 
/usr/lib/rpm/find-debuginfo.sh directly, so I think we'll need to 
preserve /usr/lib/rpm/find-debuginfo.sh path by planting a symlink to 
the real thing there (or a wrapper script if necessary). Not a big deal, 
I'll handle this from rpm.

> 
> To fix the documentation issue I submitted patches to make sure
> everything has at least a man page. I think these programs might be
> used as is by normal users. Although find-debuginfo.sh needs to stop
> depending on RPM_environment variables. So IMHO bindir is the more
> natural place to install them.

If you prefer bindir then by all means go with it.

	- Panu -

> For a 1.0 release we should make sure the documentation patches are
> there. And fix the RPM_environment variables issue:
> https://sourceware.org/bugzilla/show_bug.cgi?id=27637
> 
> Please let me know what you think of the above issues and whether there
> are any other issues that you think should be resolved before we do a
> 1.0 release.
> 
> Thanks,
> 
> Mark
>