> We want to make a package which does not break older dpkg's ... Hmm.. I presume that this means that the lowest-common denominator front-end is always available, and it's up to the user to arrange for the presence of some other front end?
> Each variable has associated with it one or more tags > (meta-information). These are used to detect if a variable has been > changed by the user or not, in much the same manner as md5sums are > used to detect changed conffiles. I was with you up to here. This one lost me. This doesn't seem to be reflected in your i/o language, and I'm having a hard time imagining how it would be a good idea. [Remember that for system stability the scripts are supposed to be idempotent -- running multiple times with the same parameters should have the same result, except for pathological circumstances.] > This communication should be as simple as possible. The simplest method > possible is using stdin/stdout to communicate. Hmm.. I was thinking that the simplest possible method is using that old standby of shell scripts: execute a command and capture its output. If nothing else, I'd think that dedicating stdin/stdout to this process would interfere with dpkg being able to install older packages which use stdin/stdout differently. > CAPB > Asks the frontent for a list of capabilities. The includes > interactiveness! This would need a bit more definition. > The frontend has complete responsibility for the layout of the questions, > with the exception that the ordering must not be changed. I'm also confused by this. I guess you're implying some kind of implicit geometrical left-to-right, top-to-bottom order for interactive use? Overall, though, this seems like it's tending in the right direction. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
