Re: Bug#3290: sysvinit path doesn't include /usr/local/{,s}bin

1996-06-28 Thread Miquel van Smoorenburg
You (Christian Hudon) wrote:
 On Thu, 27 Jun 1996, Miquel van Smoorenburg wrote:
 
  You (Ian Jackson) wrote:
   
   We need to give people the opportunity to override binaries using
   whatever practice they like.
  
  But.. but.. come on! This is *ridiculous* ! The path set in the boot script
  is only inherited by system daemons and such. All user logins go through
  /bin/login that clears the environment *anyway* ! And after that you
  can set the PATH to whatever you want in /etc/profile..
 
 Errm... That all fine and true (well except for the fact that
 you'd have to modify more than /etc/profile to change the PATH for all
 types of shells) but I don't think that's what Ian meant.
 
 From what I understood, Ian was talking about overriding binaries during
 system boot. (Or did I misunderstand you, Ian?) So if you have the PATH
 set to /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin and
 you want the system to use your custom version of mount, you just have to
 put your 'mount' in /usr/local/sbin and it'll work.

Okay. I'll try to explain it one more time, I might not have been clear
enough and re-reading this thread I've also posted some mis-information
unintentionally.

The PATH set in /etc/init.d/boot is only used in that script; remember that
you cannot modify the parents environment. If you want to change the
behavour of this script by simply putting binaries in /usr/local/sbin that
override the default binaries that won't work. An example with a custom
mount was given; but how do use use /usr/local/sbin/mount when /usr isn't
mounted yet ;) You'll have to edit the script anyway.

So modifying the PATH in /etc/init.d/boot doesn't influence any other part of
the system. On the other hand; you might want to change the PATH in
the /etc/init/rc script, that's the one that executes all other scripts
in /etc/init.d/ However that still doesn't influence programs that
are started directly by init, such as sulogin in single user mode.

The only solution seems to be to change the PATH hardcoded in the init binary
itself. This is ofcourse a bit hard to do. Therefor init has another solution;
you can let all programs executed by init go through a script called
/etc/initscript. See the manpage: initscript(8). This is turned off by default,
and for a good reason: it spawns an extra shell for everything executed
by init.

Now another thing; as I said before, I suspected that login(1) resets the
environment anyway. I checked the source and it does. You can let init
set any PATH you want; login will throw it away and install its own
PATH. That PATH is hardcoded in the binary. If you want to change that,
re-assign this bug to login.

Hope it's a bit clearer now,

Mike.
-- 
  Miquel van| Cistron Internet Services   --Alphen aan den Rijn.
  Smoorenburg,  | mailto:[EMAIL PROTECTED]  http://www.cistron.nl/
[EMAIL PROTECTED] | Tel: +31-172-419445 (Voice) 430979 (Fax) 442580 (Data)




Re: Porting and the bug reporting system

1996-06-28 Thread Ian Jackson
Martin Schulze writes (Re: Porting and the bug reporting system):
...
 But as Michael said, the bugtracking system has a long backlock.  Your
 bugs won't reach the maintainer until Ian has repaired it.

The bug tracking system is now working fine, and answering mail almost
immediately.

The only thing still waiting to be resolved is that the WWW logs are
still rather out of date, but this will be fixed when www.debian.org
(= debian.microworld.net) catches up with mirroring master.  The logs
on www.cl.cam.ac.uk are stalled waiting for effort from the mail admin
here.

When all the mirrors are up to date you'll be able to find the WWW bug
logs in the WebPages subdirectory - they're already fine on master.
In the meantime you could try using
 URL:ftp://master.debian.org/pub/Linux/debian/Bugs/index.html
 URL:ftp://master.debian.org/pub/Linux/debian/Bugs/db/index.html
(FTP doesn't do quite the right thing with directories - it fails to
use index.html).

master's ftpd appears to be shut off at the moment.

   No
 maintainer would read all your tons of bugreports that were sent to
 debian-devel, 

If the bug report has a correct Package line and the Maintainers file
on the FTP site has the right address in it the maintainer will get a
copy of the bug report sent to them directly.

These bugs should have been sent to [EMAIL PROTECTED], to stop
them from flooding debian-devel, but otherwise reporting them as bugs
is OK.

They should have been submitted with appropriate Subject lines.

I'd be grateful if someone - the original submitter, perhaps - would
use the `retitle' command at [EMAIL PROTECTED] to give them all
meaningful Subjects.

I do hope we don't have anyone around here who gets upset just because
someone files a bug against their package, provided that the bug
report isn't daft.  We should be encouraging feedback.

Ian.




Bug#3445: bug in amd package (upgrade)

1996-06-28 Thread Danny ter Haar
package: amd
Version: upl102-3

While upgrading to the latest debian version
my amd config file (/etc/init.d/amd) got overwritten. 
it is not listed as a config file and thus was disabled 
next time i booted.

Danny