On Wed, 29 Jul 1998, Wichert Akkerman wrote: > Previously Jason Gunthorpe wrote: > > You are missing what he is saying. The current proposal is that we write > > basically a script to handle the configuration prompting. A script is > > probably necessary, but I think it probably should be in the post/pre inst > > not seperate.. > > preinst/postinst is way to late, since we want all questions asked before > we start physically unpacking the packages.
What are you trying to achive? Do you want some sort of tool to pre-scan all the .debs, configure them then install? A script is necessary in the pre/postinst no matter what you decide as that is the only time configuration information can be transformed into package config files. A script MAY NOT be necessary to actually run the configuration. Bluntly, if a script is needed for more than 15% of the cases then we have failed, the system is too complex to work with. > > Value: foo/configd > > Type: boolean > > Private: yes > > Description: Controls some strange internal thing > > > > Which is ultimately more usefull? > > But you loose something there: the ability to decide if a question should > be ask, unless you implement a dependency scheme. The menuconfig of the > kernel already does that, but in a very simple way. Is this important? It doesn't hurt if the question is asked, all that happens is that the user becomes confused and a bit of space is wasted. > > The other 'missing' fragment is what to do if the user changes a database > > entry once the package is installed. It is important to leave that > > possiblity open so in future we can have 'push' configuration. > > So you want the ability to add a trigger? You attach a trigger to a part > of the database, and when the part is changed the trigger is triggered > and gets to do something, like reconfigure a package? Yep - but perhaps there are other ways than what you are describing.. Jason -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
