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

dpkg mechanism suggestion



Please tell me what think of this idea, whether it's pratical etc...

Problems:
 - many postinst scripts contain non-critical stuff. They often halt for user
   prompts.
 - many things are called in several postinst scripts. This way duplicate work
   is done.

two new functions for dpkg :
 - dpkg-once: do this once after work with all packages. May only be used for
   non-critical, non-interactive stuff. Default example: update-menus
   and similiar programs.
 - dpkg-todo: do this once after work with all packages, or anytime later,
   at users request. May only be used for non-critical, interactive stuff.
   Examples : <everything>-config. This allows people to first read
   documentation, and then decide whether to activate/install it.
   Also usefull, where client and server is in the same package : you can use
   the client, without running a server (e.g. ntpdate/xntpd, cvs).

   the program will maintain a TODO list, so you can do things later.
   you can choose :
    - configure everything ASAP (after dpkg did the normal work),
    - present the TODO list what needs to be configure after every dpkg run
    - quiet mode, don't say anything, wait till the sysadmin calls the
      frontent himself to look what needs to be done.
    - auto/max-enable: enable everything ("i know what i'm doing").
      will e.g. enable all deamons if you install the package 
      (good for admins, but newbies shouldn't use it ...)

i think this will make installation easier. it has a simple design, and is
easy to implement. once there is something better (like that proposed
question/answer databse, or so), it can be replaced

i simple don't want to wait another year, till coas is done. this is not an
admintool, but admintools could be enhanced to use these functionalities.

i guess the changed to dpkg are minimal (at the end : call the two programs
with "dpkgfinish" parameter).

implementation in perl will be easy. if you want c, i can do it that way.
for the dpkg-todo, there will be several frontends :
 - command line. the users gave the program to call.
 - serial mode. some printf's, and call the commands one after each other.
 - serial/question. some printf's, ask yes/no and call the commands (if y)
 - text/select: give a list of things to be done, and call them.
 - x11|ncurses|slang|gtk|.../select: same list, but easier to navigate...

the programs should go into the dpkg package.

comments ?

andreas


Reply to: