Previously Raul Miller wrote: > > 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?
Correct. The simplest implementation being a simple thing which just prints/asks the things one at a time. The desing says somewhere (or should) that multiple questions can be presented in the same time, but never says that is obligatory. > > 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. meta-data is actually quite simply. What I hand in mind mostly was a tag which says if the variable was set by a package or by a user. This way when a configmodule does DSET and the frontend sees from the metadata the variable was last set by the user and not by the package, it refuses to change the variable since it isn't the default already. > 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.] It's the same idea as the md5sums for conffiles dpkg currently keeps. I just wanted to be able to think of more meta-data tags in the future, so that's why I was a bit vague here. I'll add some more text on it in the next version. > 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. But that's something different: stdin/stdout are only refocused for the configuration-module. And that already knows that and still has stderr open for errors. The other scripts run just as before. > > CAPB > > Asks the frontent for a list of capabilities. The includes > > interactiveness! > > This would need a bit more definition. The idea was to be able to add optional features to the frontend and make it possible for the configmodule to check for there existance. > > 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? Indeed. It's something like html or LaTeX: you specify the function of something (string input, static text, etc.) and let the frontend decide how to display that. > Overall, though, this seems like it's tending in the right direction. Thanks! Feedback like this is very much appreciated if we ever want to start with this. Wichert.
pgpqQ6xLXbKR4.pgp
Description: PGP signature
