A recent change in the iproute2 package moved the installed location
of the "ip" program from /bin/ip to /usr/bin/ip with the
iproute2-6.5.0-5 packaging.  That's all well and good of course.

On systems using sysvinit and not yet UsrMerged this snags a problem
in the sysvinit init script.  I know and understand that this is not a
combination that you or Debian is officially supporting.  But it would
help out interoperability if a one line fix were applied and your
kindness would be appreciated.

Here is the patch that corrects the problem.
--- named.original      2023-09-20 10:13:07.000000000 -0600
+++ named       2023-11-05 14:58:49.277781923 -0700
@@ -32,7 +32,7 @@
     if [ -x /usr/bin/uname ] && [ "X$(/usr/bin/uname -o)" = XSolaris ]; then
         LIST_NICS_IP=$(/sbin/ifconfig -au) || result=$?
     else
-        LIST_NICS_IP=$(/bin/ip addr) || result=$?
+        LIST_NICS_IP=$(ip addr) || result=$?
     fi
     if [ $result -ne 0 -o -z "${LIST_NICS_IP}" ]; then
        #log_action_msg "No networks configured."

PATH is already set and there is no need to use a hard coded path for
that program.  Doing so results in this situation now where movement
of the program executable causes failure.  Better just to call it and
have it be found on PATH.

Thank you for maintaining bind9 in Debian!

Bob

Hi Bob,

I understand you are not using Debian. Please indicate that if you file
bugs encountered on other distributions.
a
would
to support split-usr and it will not work very well for shell
interpreter lines like "#! /bin/bash" when the basy binary gets
installed to /usr/bin/bash.

So to me it seems pretty useless to fix singular instances of this
problem.

It would probably be better for your distribution to fix this. Please
file a bug with them.

You said elsewhere that this was a bug coming from using a different
distribution. Please talk to them so they make sure the system
information says so when people are using it.

Ansgar

On Mon, 06 Nov 2023 08:54:39 +0100 Ansgar wrote: > Hi Bob, > > I understand
you are not using Debian. Please indicate that if you file > bugs
encountered on other distributions. > > > On systems using sysvinit and not
yet UsrMerged this snags a problem > > in the sysvinit init script.  I know
and understand that this is not > a > > combination that you or Debian is
officially supporting.  But it > would > > help out interoperability if a
one line fix were applied and your > > kindness would be appreciated. > >
This approach does not scale: it would require maintainers to continue > to
support split-usr and it will not work very well for shell > interpreter
lines like "#! /bin/bash" when the basy binary gets > installed to
/usr/bin/bash. > > So to me it seems pretty useless to fix singular
instances of this > problem. > > It would probably be better for your
distribution to fix this. Please > file a bug with them. > > > -- System
Information: > > Debian Release: trixie/sid > >   APT prefers unstable >
(x86_64) > > You said elsewhere that this was a bug coming from using a
different > distribution. Please talk to them so they make sure the system

why not /usr/bin/env bash
also its not a problem with the distribution if it doesnt do usrmerge

Ansgar wrote:

That is a straw man argument fallacy as you are trying to refute
something that was not in the original request.  I have not asked for
adding in a hard coded path.  I am asking to have a hard coded path
removed.  That's just good programming practice and should be valid on
any system.  It just happens to be in a shell script.  There was no
request to change anything about script #! interpreters.

I tried to be as clear on the issue as possible that while I
understood that it was not a supported configuration that it would be
of a help if the removal of the hard coded path could occur.  The
removal of five characters from one line of the file.  It is a small
thing but it would help out.  Perhaps for the next time the package
has a normal release?

No.  I said this was on Debian systems without systemd and that have
not been UsrMerged.  I said that I realized this is not a supported
configuration.  I am a long time user of Debian and have quite a few
variously hacked installations.  Debian used to have the tag line that
it was The Universial Operating System.  We would joke that it would
run on toasters.  It runs on the space station for goodness sakes!
That was because it used to be a flexible system and these types of
local configuration modifications is what made Debian the best choice
for custom systems.

Bob