Re: package configuration design
> 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 debian-policy-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: