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

Re: Proposal: Automatic query servicing for dpkg installation scripts



Raul Miller writes ("Re: Proposal: Automatic query servicing for dpkg installation scripts"):
>I think that better examples could be had (in principle, xfig should
>always use colors unless the display doesn't have enough color or unless
>a mono command line switch is provided; dotfile-xxx should have a decent
>default for executable scripts, perhaps patterned after emacsen or tex).

It uses X resources, it should use the standard colors (mono) unless
the "customization" X resource is set.

I always run it mono here since most of my users consider the
technicolor fruit-salad dialog boxes "hideous"... :)

>xmcd is a better example (and it also provides for configuration
>independent of install, which is also an issue).

Yes, xmcd seems to do a good job of this.

>8) Administrator defined points of control.
>
>   At one extreme, the administrator wants the package system to keep
>   its hands off of carefully hand-tuned configuration files (we do this
>   fairly well right now, though there's probably room for improvement),
>   at the other extreme, the administrator wants to specify information
>   once and have it flow into a number of existing systems and new
>   installations (we don't even come close at the moment). 


We certainly don't, that's why I do *one* install of packages, and
then either 'tar' or 'dd' to copy it to other machines.

>   A typical installation would have one machine that the administrator
>   wants to be mostly auto-configured, and maybe eventually a second
>   machine which (as a starting point) should reflect the configuration
>   of the first machine.

I would be in heaven if I could automate my installs (maintaining
dozens of linux boxes with hundreds of users on 10 hr/wk is a bit of a
challenge)

-- 
Richard W Kaszeta 			Graduate Student/Sysadmin
bofh@me.umn.edu				University of MN, ME Dept
http://www.menet.umn.edu/~kaszeta


--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org


Reply to: