public inbox for debugedit@sourceware.org
 help / color / mirror / Atom feed
* Some package review feedback (bindir vs libexecdir, docs and find-debuginfo.sh naming)
@ 2021-04-30 12:33 Mark Wielaard
  2021-05-05 22:59 ` Mark Wielaard
  2021-05-06  9:48 ` Panu Matilainen
  0 siblings, 2 replies; 3+ messages in thread
From: Mark Wielaard @ 2021-04-30 12:33 UTC (permalink / raw)
  To: debugedit; +Cc: ngompa13, pmatilia

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Some package review feedback (bindir vs libexecdir, docs and find-debuginfo.sh naming)
  2021-04-30 12:33 Some package review feedback (bindir vs libexecdir, docs and find-debuginfo.sh naming) Mark Wielaard
@ 2021-05-05 22:59 ` Mark Wielaard
  2021-05-06  9:48 ` Panu Matilainen
  1 sibling, 0 replies; 3+ messages in thread
From: Mark Wielaard @ 2021-05-05 22:59 UTC (permalink / raw)
  To: debugedit; +Cc: ngompa13, pmatilai

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Some package review feedback (bindir vs libexecdir, docs and find-debuginfo.sh naming)
  2021-04-30 12:33 Some package review feedback (bindir vs libexecdir, docs and find-debuginfo.sh naming) Mark Wielaard
  2021-05-05 22:59 ` Mark Wielaard
@ 2021-05-06  9:48 ` Panu Matilainen
  1 sibling, 0 replies; 3+ messages in thread
From: Panu Matilainen @ 2021-05-06  9:48 UTC (permalink / raw)
  To: debugedit

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
> 


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2021-05-06  9:48 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-04-30 12:33 Some package review feedback (bindir vs libexecdir, docs and find-debuginfo.sh naming) Mark Wielaard
2021-05-05 22:59 ` Mark Wielaard
2021-05-06  9:48 ` Panu Matilainen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).