[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#634246: marked as done (apt: PATH not propagated down to maintainer scripts)

Your message dated Fri, 14 Aug 2015 00:10:00 +0200
with message-id <20150813221000.GA31726@crossbow>
and subject line Re: apt: PATH not propagated down to maintainer scripts
has caused the Debian Bug report #634246,
regarding apt: PATH not propagated down to maintainer scripts
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
634246: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=634246
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: apt
Version: 0.8.14.1
Severity: normal


I have a handful of scripts in /usr/local/sbin that I supposed would
override system programs of the same name, and would get picked to run
from maintainer scripts in preference to the system ones because
/usr/local/sbin is first in root's PATH.  The programs thus fooled are
of the adduser variety.

That never worked as I intended.  Of course initially I thought it was a
bug in my replacement scripts, but they are quite trivial (doing nothing
at all in the del* case, for example), so I eventually came to suspect
they simply never get control.  Now I am 100% sure.

This could happend for a number of reasons.  PATH could be explicitly
reset to a hardcoded value, or /usr/sbin could be prepended to the
ambient PATH, or some program that wipes the environment clean might be
run "between" aptitude and the maintainer scripts.  I am thinking of su
here, as I have seen a number of places where it is used in the aptitude
source.  I run aptitude as root though, so I don't know why it would su.

Unfortunately I really don't know which of these possibilities is true
or even which of the morass of packages (aptitude, apt, dpkg, ...)  is
responsible.  I tried to track it down but it was taking way too much
time :-(

Well, I just tried with command-line apt-get, and it doesn't work
either.  So I guess I can eliminate aptitude as the culprit.  Filing
against apt, please reassign if necessary.


-- 
Ian Zimmerman
gpg public key: 1024D/C6FF61AD
fingerprint: 66DC D68F 5C1B 4D71 2EE5  BD03 8A00 786C C6FF 61AD
Rule 420: All persons more than eight miles high to leave the court.

--- End Message ---
--- Begin Message --- 
On Sun, Jul 17, 2011 at 11:12:22PM -0700, Ian Zimmerman wrote:
> This could happend for a number of reasons.  PATH could be explicitly
> reset to a hardcoded value, or /usr/sbin could be prepended to the
> ambient PATH, or some program that wipes the environment clean might be
> run "between" aptitude and the maintainer scripts.  I am thinking of su
> here, as I have seen a number of places where it is used in the aptitude
> source.  I run aptitude as root though, so I don't know why it would su.

Just tested, PATH is passed from apt-get to dpkg to maintainerscripts
like the rest of my environment. So that was fixed in the meantime and
hence I am closing this report.


Best regards

David Kalnischkies

Attachment: signature.asc
Description: Digital signature


--- End Message ---
Reply to: