Well, I promised myself I wasn't going to get involved in this kind of thing, but I'm about to get a private internet connection so I should be able to insulate my job from these discussions soon. I would like to make the following requests of those working on this project:
Please do not create a proprietary configuration interface. Any admintool should not require people to use it. In other words, if an admintool uses a textdb tool, they should be used to create "standard" config files that anyone can administer themselves (without these tools) and possibly distribute to non-debian systems. If I have a UUCP config for Taylor UUCP version X on my debian box, my config files should plug and play on any properly installed Taylor UUCP version X. The same goes for X11, xdm, TeX, lpr, etc. Package maintainers could make use of the textdb tool to "register" config values shipped with their package, or retrieve values stored from a previous installation, but not to replace upstream config/setup/startup files that would not have otherwise been replaced by debian. The tool(s) should not enforce policy, but rather be generally useful to be able to conform to policies. Discussing how we should change the debian policy because we want to make a tool that acts a certian way is a bad idea. Develop the tool. Let it be used to implement current policy. If and when policy changes, the tool should not need to be rewritten to implement new policy. Basically, please leave the policy discussion out of the developement discussion. Users may not like debian policy and may have their own. They should be able to use the tool to implement a site/company specific policy (which may be a replacement for, subset of, or superset of debian policy) for any given package. The web policy is prime candidate for this sort of thing. One more request: please don't over-simplify the _usage_ of the tool. A very simple tool could be used to do very sophisticated things. Storing state information about configurable data and global/package-level behavior flags regarding upgrades/installations, etc. are all possible with cfgtool if its used by a wrapper that just calls cfgtool to put/get/modify data. The virtual structure of the data does not need to be limited to its physical structure. I'm only subscribed to debian-admintool at the moment, so please keep the discussion at least CC'd there. Thanks Richard G. Roberto [EMAIL PROTECTED] 011-81-3-3437-7967 - Tokyo, Japan -- ******************************************************************************* Bear Stearns is not responsible for any recommendation, solicitation, offer or agreement or any information about any transaction, customer account or account activity contained in this communication. ******************************************************************************* -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
