I noticed some time ago that my pretty old custom dpkg-conffile-diff
script is not available (without giving full path to it, which is
/usr/lcoal/sbin/dpkg-conffile-diff) in the shell spawned by dpkg to
handle config file merges during installations.

Today I've found some time to investigate it, and found this commit
in apt:
https://salsa.debian.org/apt-team/apt/commit/806e94dcd8dbdf7bf1909657fd4331cfe17b4ab0
    Set PATH=/usr/sbin:/usr/bin:/sbin:/bin when running dpkg

    This avoids a lot of problems from local installations of
    scripting languages and other stuff in /usr/local for which
    maintainer scripts are not prepared.

(To be honest I am not sure if such change should be done in apt;
if it is really needed then most probably dpkg should do it on its own).

It would be nice if dpkg could restore the default root path, i.e.
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
for a shell spawned for interactive config file handling.

If you think this bug should be fixed by apt somehow, feel free to
reassign it.


Regards,
robert

I can't speak for Julian who implemented that based on a rather constant
stream of issues reported for that in launchpad (and beyond), but
I guess that could be equally well/better solved by having a way of
controlling the environment a maintainer script is executed in
somewhat independent of the environment dpkg is called from.

PATH is just one of many interesting environment variables which can
produce bad results in unsuspecting scripts. GREP_OPTIONS comes
to mind for example while other variables should be passed on for e.g.
debconf frontends to make use of.

If dpkg, apt or X contain the actual configuration is a matter of
opinion mostly I guess, I can at least envision it being argued both
ways.


Best regards

David Kalnischkies