[Ron] > This definitely should start in rcS, ie. be run once at boot, and > not when changing runlevels. I don't see anything that explicitly > requires syslog in the code though, so I'm guessing that either it > was in rcS too when I first added the LSB headers to this, or I > cargo-culted that one in accidentally. Either way, I agree it looks > like it can go now and we don't need it.
Note that it is not required to start in rcS.d/ to only run once at boot. An (better in my opinion) option is to start in the runlevels 1-5, as a script that was started in the previous runlevel is not started again when switching. Please do this if possible, to reduce the stuff executed when booting into single user mode. Ie I recommend to use Default-Start: 1 2 3 4 5 Default-Stop: instead of Default-Start: S Default-Stop: I recently asked for the sudo script to move from rcS.d/ to runlevels 1-5, and strongly recommend other scripts to do the same, as part of my long term plan to clean up the single user mode. :) In principle, only scripts that need to run before single user mode should be executed in rcS.d/. The rest should start in runlevels 1-5. :) > This one looks a bit more curly. The current console-tools/kbd maintainer > asked me to switch this back to kbd after etch, since console-tools was > supposedly going to be removed -- that apparently hasn't happened yet, > but since console-screen is from console-tools, it shouldn't even be on > the same system as STM. > > console-setup is new, and indeed looks like it will 'conflict' with STM > about setting the console font and the like. I'm not really sure if or > how compatible they are with each other, and I'm not sure I even have > suitable hardware here to test it with. I haven't actually run STM myself > for many years now, but quite a few people still seem to love it and it is > usually low maintenance enough that with their help we can keep it alive. > > We might need someone to do some tests for this ... I do not know the status of the console setup scripts, but have discovered that they seem to do the same job and should because of this have a predictable order to avoid undefined behaviour when several of them are started on the same system. >> Last, I suspect the script need direct access to the >> pty when concurrent booting is enabled, and because of this should be >> flagged as interactive. > > It may echo a few things to the console, but it shouldn't prompt for input. > I don't see any docs on what X-Interactive is supposed to imply. It needs > direct access to the tty to read and set configuration though, since it > likely resizes the console. X-Interactive is supposed to imply prompting, but is also needed for scripts requiering direct access to the tty/pty. > So ... if you let me know what the deal is with X-Interactive and > whether or not we do really need it, and we figure out which of the > other consoleFoo tools really are going to be the default for > squeeze and how they should interact with STM (or if they can at > all) -- then I'll push an updated package out. I'm really not that > familiar with where the current console handling is going right now, > so I'm going to need some good advice on that from the people who > do. Great. ) Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
