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

RFC: A method to use Admin tools, like linuxconf



Pleae remember that this is my first stab at writing a document like this,
they don't teach skills like this in my high school, so obviously I am
lacking a little, any constructive criticism will be appreceated for
writing documents like this.

PURPOSE:  This RFC proposes a method for linuxconf, or any future admin tool,
          to be plugable into Debian with a minimal amount of trouble.

REASON:   Many people, including myself, have asked "Is it possible that we
          can use Linuxconf with Debian."  Linuxconf is a good thing, but for
          a person to use it under present conditions in Debian, would mean 
          that he would have to give up any future upgradability.  If we were
          to move to linuxconf, it would have the side effect of being
          incompatible with any future admin tool that comes around, and it
          most likely would even be incompatible with plain SysV init.  There
          has to be a more elegant solution.

ABSTRACT: Each package would contain a "database" file, in addition to the  
          control, and {pre,post}{inst,rm} scripts.  This "database" file
          will contain fields, that a "configure" program can use to create
          the appropriate files for the admin tool, so that the admin tool
          can know about these new packages.

PROPOSAL: Right now every package that needs to install init scripts, call
          "update-rc.d" to "tell" SysV init about these packages and when it
          needs to run them.  This idea can be taken further to include any
          admin tool that wants to take over the system.  We can keep our 
          start-stop daemon and the scripts in /etc/init.d for starting and 
          stopping the programs and with the addition of the "database" file,
          we can provide all the information the admin tools will need to 
          configure themselves.

          Instead of each package calling "update-rc.d" in their postinst
          scripts, they will call a generic command, "configure" will call it.
          Each admin tool will provide their own version of "configure" and 
          their "configure" will know how to build the appropriate files for 
          the admin tool from the "database" file in the package.  This can
          enable us to support many different admin tools without making the
          maintainer go through any more work.  

          The "configure" program will take the "database" file contained in 
          the package (which can possibly be folded into the central database
          idea) and by using fields in it such as STOP and START (which should
          be /etc/init.d/(script) {stop,start}).  The "configure" program will
          take the database file, and use all the fields in it that it needs, 
          and will build the appropriate files, "drop-ins" or whatever the
          admin tool needs, so that the admin tool will "know" about these new
          packages.

          In order to ensure that only one admin tool is installed at a time,
          the packages that these admin tools will be part of should PROVIDE,
          CONFLICT, and REPLACE the virtual package "admin-tool".  According 
          to my limited knowledge of how the dependencies work, this should
          prevent two admin tools from being installed at once.

          In order to keep backwards compatibility with SysV init, in case
          anything goes wrong, each admin tools "configure" program would also
          perform the same function that "update-rc.d" performs now.  It would
          install the appropriate links into the /etc/rc{1,2,3,4,5,6}.d tree.
          This would also provide us with the ability to remove an admin tool,
          and keep a perfectly usable system for keeps or until a new admin 
          tool is installed.  Each admin tool would also copy
"default_configure" to "configure" in their prerm scripts.  This 
          program would act just like plain "update-rc.d" acts now, it will
          just install plain links into the /etc/rc{1,2,3,4,5,6}.d tree. 
          This will ensure that SysV init will always be in working order.

          By having the capability in Debian, of having the ability to use
          different admin tools if you want, or none if that is your wish, we
          will in many ways leap far ahead other distributions in our 
          configurability, while still retaining our ability to upgrade the
          system with ease.  This would continue the tradition of packages
          like menu, which enable many packages to work in a harmonious way 
          with our system installed

Thanks for reading this,

Shaya



--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com


Reply to: