Re: [arch-general] [arch-dev-public] [signoff] vc/* -> tty* transition
On Sun, 2009-07-19 at 12:01 +1000, Allan McRae wrote:
First off, I don't like modifying config files. But, given I did this update and still managed to screw my system up when testing it with a reboot...
So it is a question of which I hate more; post install messages or automatically fixing the file.
A post install message means that I tell all complaining users that they should have read their pacman output. But hang on, they are already told that there is a .pacnew file for what is a very important config file. So I can say that anyway. So here is my prototype install file...
post_install() { if [ -f "/etc/inittab.pacnew" ]; then echo "You are being very stupid if you did not take notice of that warning about a .pacnew file" fi }
A simple sed of the config file means much, much less complaining users. And given the number of complaints I got about libjpeg7 (wheres the thanks now gtk and kde are working?), I am very, very tempted just to do the sed.
Allan
Not that my option means squat but.... I agree. Since this update/upgrade will break everyone/most peoples systems I think a relaxing of the rule for this one is justified . Rules are meant to be broken, that's why there are rules :) You do want to be a distro without rules don't you?
FWIW, I subscribe to this list and have read every post in this thread, and my system was killed because I didn't fix the file before a reboot out of my own laziness. It took me all of 2 minutes to fix my system. Could it have been prevented? Yes. Do I really give a shit that I had to fix it? No, because it was my own fault. Had this been one of the remote machines that I administer I would have been more careful when doing the upgrade and this wouldn't have happened. I think of out all the options here, copying the current inittab to .pacsave and installing a new, working inittab makes the most sense. Then a user would at least have a chance to boot and read their logs to see what happened if they even notice there is a problem.
On Sun, Jul 19, 2009 at 10:23, Randy Morris<randy.morris@archlinux.us> wrote:
I think of out all the options here, copying the current inittab to .pacsave and installing a new, working inittab makes the most sense. Then a user would at least have a chance to boot and read their logs to see what happened if they even notice there is a problem.
This is exactly what Arch *doesn't* do, and it provides .pacnew files for this purpose.
On Sun 19 Jul 2009 13:43 -0400, Daenyth Blank wrote:
On Sun, Jul 19, 2009 at 10:23, Randy Morris<randy.morris@archlinux.us> wrote:
I think of out all the options here, copying the current inittab to .pacsave and installing a new, working inittab makes the most sense. Then a user would at least have a chance to boot and read their logs to see what happened if they even notice there is a problem.
This is exactly what Arch *doesn't* do, and it provides .pacnew files for this purpose.
Well, I do think saving the current config as a pacsave is a hell of a lot better than altering it and wondering what the hell happened to your original config. So that's a compromise I'd be willing to accept.
On Sun, Jul 19, 2009 at 7:43 PM, Daenyth Blank<daenyth+arch@gmail.com> wrote:
On Sun, Jul 19, 2009 at 10:23, Randy Morris<randy.morris@archlinux.us> wrote:
I think of out all the options here, copying the current inittab to .pacsave and installing a new, working inittab makes the most sense. Then a user would at least have a chance to boot and read their logs to see what happened if they even notice there is a problem.
This is exactly what Arch *doesn't* do, and it provides .pacnew files for this purpose.
But in this special case, you could always do : sed -i'.pacsave' 's#vc/\([0-9]\)#tty\1#' /etc/inittab
participants (5)
-
Baho Utot
-
Daenyth Blank
-
Loui Chang
-
Randy Morris
-
Xavier