public inbox for debugedit@sourceware.org
 help / color / mirror / Atom feed
From: Mark Wielaard <mark@klomp.org>
To: debugedit@sourceware.org
Cc: ngompa13@gmail.com, pmatilia@redhat.com
Subject: Some package review feedback (bindir vs libexecdir, docs and find-debuginfo.sh naming)
Date: Fri, 30 Apr 2021 14:33:59 +0200	[thread overview]
Message-ID: <c5158dee427707ddf77559e2a070f83244c8178b.camel@klomp.org> (raw)

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

             reply	other threads:[~2021-04-30 12:34 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-30 12:33 Mark Wielaard [this message]
2021-05-05 22:59 ` Mark Wielaard
2021-05-06  9:48 ` Panu Matilainen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c5158dee427707ddf77559e2a070f83244c8178b.camel@klomp.org \
    --to=mark@klomp.org \
    --cc=debugedit@sourceware.org \
    --cc=ngompa13@gmail.com \
    --cc=pmatilia@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).