Raul Miller wrote:
> Joey Hess <[EMAIL PROTECTED]> wrote:
> > > Finally, I don't think we can completely get rid of interaction
> > > with the user at install time.
> >
> > I think we can.
>
> You think we can safely toss the "Are you sure?" prompts?
We can do the "are you sure" prompts in the c
Joey Hess <[EMAIL PROTECTED]> wrote:
> > Finally, I don't think we can completely get rid of interaction
> > with the user at install time.
>
> I think we can.
You think we can safely toss the "Are you sure?" prompts?
--
Raul
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "
Martin Oldfield <[EMAIL PROTECTED]> wrote:
> Raul> Note that most packages do not require such a state machine.
>
> True, although I note the obvious fact that this is a special case of
> a state machine with a simple transition matrix: if the verification
> script returns 0 on OK, and -1 on e
Raul Miller wrote:
> I'm not convinced that installation scripts are the right place for
> packages which do require such complicated configuration. As a
> general rule, when configuration gets that complex you're going to
> want to use the same tool for reconfiguration.
This is why many of the c
> "Raul" == Raul Miller <[EMAIL PROTECTED]> writes:
--> Joey's comments snipped <--
Raul> Note that most packages do not require such a state machine.
True, although I note the obvious fact that this is a special case of
a state machine with a simple transition matrix: if the verificatio
Joey Hess <[EMAIL PROTECTED]> wrote:
> That's actually a good summary of where I think we're headed. However, I
> think you need to allow each package to provide a state machine. We need this,
> becuase there's no way some generic state machine is going to be able to
> present the data to the user
Previously Antti-Juhani Kaijanaho wrote:
> On Thu, Jul 30, 1998 at 01:45:18AM +0200, Wichert Akkerman wrote:
> > I was thinking about a language which seperates the two: first you
> > declare all variables you want to use and give each a priority. In the
> > next section you state dependencies bet
Martin Oldfield wrote:
> Isn't the obvious generalization to divide configuration questions
> into blocks, then specify a state machine to navigate between blocks ?
>
> I think it would be good tohave a very general verification mechanism:
> were we to implement this in perl, then we could just pr
On reflection I think you're right, it's not clear the inheritance
buys much save extra complexity. It was only a flippant comment.
How does it all work if there's a simple list of sources of data in a
file in /etc/ where that machine looks for config stuff ? A simple URL
probably works well and a
Martin Oldfield <[EMAIL PROTECTED]> wrote:
> configurations there I wonder ;*) More seriously I think an
> inheritance hierarchy is a better model.
Better than what?
Inheritance is a mess when you don't sit down and carefully design the
system ahead of time. And, frankly, I don't think that prov
> "Raul" == Raul Miller <[EMAIL PROTECTED]> writes:
Raul> Martin Oldfield <[EMAIL PROTECTED]> wrote:
R> Er, if you don't mind that you have a nondeterministic state
R> machine (for example: all possible states exist in parallel)
R> when you're describing the configuration for m
Martin Oldfield <[EMAIL PROTECTED]> wrote:
> R> Er, if you don't mind that you have a nondeterministic state
> R> machine (for example: all possible states exist in parallel)
> R> when you're describing the configuration for many machines.
>
> Is this the right way to think about it ?
> "R" == Raul Miller <[EMAIL PROTECTED]> writes:
R> Martin Oldfield <[EMAIL PROTECTED]> wrote:
>> Isn't the obvious generalization to divide configuration
>> questions into blocks, then specify a state machine to navigate
>> between blocks ?
R> Er, if you don't mind that y
Martin Oldfield <[EMAIL PROTECTED]> wrote:
> Isn't the obvious generalization to divide configuration questions
> into blocks, then specify a state machine to navigate between blocks ?
Er, if you don't mind that you have a nondeterministic state machine
(for example: all possible states exist in p
Isn't the obvious generalization to divide configuration questions
into blocks, then specify a state machine to navigate between blocks ?
Within a block a series of questions are specified which are passed to
some front end which interogates the user. Within block questions
aren't ordered; I ima
Previously Jason Gunthorpe wrote:
> > I strongly suspect that if we take a carefull look at what the
> > configuration scripts are asking we will find this is not a major hurdle
> > for MOST things - and a such should not be the central focus of any
> > proposal.
Wichert Akkerman <[EMAIL PROTECTED
Antti-Juhani Kaijanaho wrote:
> Does this help at all?
Yes, I understand where you're coming from.
> You just found the first genuine bug in my idea. Congratulations. It
> is not fatal, however. Here is one way of fixing it. If you need to
> have one set of questions or another set if questio
On Thu, Jul 30, 1998 at 04:08:59PM -0700, Joey Hess wrote:
> Antti-Juhani Kaijanaho wrote:
>
> I don't understand the meaning of "decisions" you are using.
I'm talking about the decisions over what actually gets asked.
Unfortunately no RFC describes a protocol for transferring thoughts
from one'
Antti-Juhani Kaijanaho wrote:
> There is a fundamental difference. The new model allows the frontend
> make the decisions, based on the constraints set by the package's
> configmodule. In the original model the decisions were hardwired into
> the configmodule, and if you wanted to change the deci
On Thu, Jul 30, 1998 at 01:05:55PM +0200, Ronald van Loon wrote:
> How about XML ? It's rather easy to parse, to extend etc. Just
> define a bunch of tags and attributes, and le voila. Done.
On the one hand, as XML is a metalanguage, you would still be defining
a new language. No gain from that p
On Wed, Jul 29, 1998 at 05:01:54PM -0700, Joey Hess wrote:
> Let me ask you: how is this proposal for a language implemented in
> the frontend different that the original proposal for a shell script
> that that communicates with the frontend?
There is a fundamental difference. The new model allo
On Wed, Jul 29, 1998 at 10:56:46PM -0700, Joey Hess wrote:
> It already has if statements.
No, no, no, no, no!
The language I described doesn't have any statements at all, not if
statements nor any other statements. You would need a flow of control
for having statements. But no flow of control
Antti-Juhani Kaijanaho <[EMAIL PROTECTED]> writes:
> I realize that this language requires a more sophisticated parser than
> Akkerman's original, but IMO it would be worth it. And I don't think
> the parser needs to be /that/ sophisticated :-)
Mmmm. Prefix syntax (best Homer Simpson drooling no
On Thursday, July 30, 1998 12:46 PM, Antti-Juhani Kaijanaho
[SMTP:[EMAIL PROTECTED] wrote:
> On Thu, Jul 30, 1998 at 10:05:53AM +0100, Martin Oldfield wrote:
> > Rather than writing yet another language why don't we just use an
> > existing one ? Whilst it's true that you don't want to force a use
On Wed, Jul 29, 1998 at 04:21:59PM -0700, Joey Hess wrote:
> You've just re-invented lisp. ;-)
No I haven't. The syntax I used is similar to Lisp, on purpose. And
I did mention it. However, on a production system, the syntax need
not be Lisp-like, I just used it because I had to pick a syntax f
On Thu, Jul 30, 1998 at 10:05:53AM +0100, Martin Oldfield wrote:
> Rather than writing yet another language why don't we just use an
> existing one ? Whilst it's true that you don't want to force a user to
> learn say perl just so that he can write his software, it's surely
> better that he learns
> "Antti-Juhani" == Antti-Juhani Kaijanaho <[EMAIL PROTECTED]> writes:
--> snip <--
>> Even if the parser is (somewhat) complicated, we only need to
>> implement it once.
Antti-Juhani> Right. It should be put in a shared library IMHO.
Antti-Juhani> Oh, and BTW, I think this
Antti-Juhani Kaijanaho wrote:
> > I was thinking about a language which seperates the two: first you
> > declare all variables you want to use and give each a priority. In the
> > next section you state dependencies between the variables and possibly
> > a decision process.
>
> Yes! This is how
On Thu, Jul 30, 1998 at 01:45:18AM +0200, Wichert Akkerman wrote:
> (nesting example removed)
It wasn't a nesting exmple. :-)
> I was thinking about a language which seperates the two: first you
> declare all variables you want to use and give each a priority. In the
> next section you state de
Craig Brozefsky wrote:
> Joey Hess <[EMAIL PROTECTED]> writes:
> > It already has if statements. Richard said he wanted to add some stuff to
^ Wichert, not Richard. oops
> Agreed. I think it's a bit on the complicated side already. I was
> answering your questi
Joey Hess <[EMAIL PROTECTED]> writes:
> It already has if statements. Richard said he wanted to add some stuff to
> make it more complex. At some point it stops becoming a representation and
> becomes a turing-complete language and then you're no better off than you
> were before.
Agreed. I thin
Jason Gunthorpe wrote:
> I don't see why shell can't be used, so long as it provides the
> flexability we are looking for..
>
> How would the shell script be sent to the user? We can put the value tree
> inside a file on the ftp site, but a script could be quite large+complex..
I wasn't proposing
Craig Brozefsky wrote:
> The shell is not really as expressive a data representation language
> as the specialized scheme like language. Forget for a moment that it
> has parenthesis, it doesn't really matter what the syntax is at this
> moment.
It already has if statements. Richard said he want
On Wed, 29 Jul 1998, Joey Hess wrote:
> > Look at it from a broader perspecive, how will a Pre-Configuration GUI
> > look for N packages, what options will the user have, how will they
> > interact with it? Do you envision a simple series of prompts or as some
> > sort of exploritory tool allowin
Joey Hess <[EMAIL PROTECTED]> writes:
> Won't each frontend have to implement it?
Not, it's only a description. A frontend could be given access to it
in any manner, You could even write a C interface that returns
structs based on the description, or whatever.
> I think we're going off on a po
A while back in this thread I asked if there was some way a "back" button
could be implemented to return to previous questions in a configuration
script. Here's one way to do this - this is a modification to Wichert's v3
propsal:
After each GO command, the frontend should return a result status
Joey Hess wrote:
> This latter obviously is more what we want. My point was that neither
> Wichert's proposal nor Antti-Juhani Kaijanaho's proposal accomplish this.
Forgot to add, I think the way to make Wichert's propsal implement this is
simply to break out a control file that lists all the valu
Jason Gunthorpe wrote:
> The distinction doesn't have make much difference when you look at a
> single package, who cares if it pulls or pushes, it does it's query thing
> and then it's done - either way it works.
>
> Look at it from a broader perspecive, how will a Pre-Configuration GUI
> look fo
On Wed, 29 Jul 1998, Joey Hess wrote:
> Why don't we then just send the frontend a lump of shell code and use that
> as our implementation language? The only reason I see why not is that then
> the frontend would have to parse the shell code. Well, then, why not make
> there be an interface betwe
On 29 Jul 1998, Miquel van Smoorenburg wrote:
> Hmm, has noone in this thread mentioned COAS yet? http://www.coas.org/
> It is ment to be a complete Linux administration package, with plugin
> modules for every package. If we just provided the configuration
> module with each package, COAS could
Wichert Akkerman wrote:
> I happen to like playing around with parsers and compilers. I'll see if
> I can come up with a nice design :). Even if the parser is (somewhat)
> complicated, we only need to implement it once.
Won't each frontend have to implement it?
I think we're going off on a pointl
Previously Antti-Juhani Kaijanaho wrote:
> Let's start with a very simple package, xyzzy. The only thing it
> needs to know is whether the system clock is set to UTC or not.
> How to present this to the frontend? Clearly we need to give it a
> named aggregate of pairs (consisting a label and a
Previously Miquel van Smoorenburg wrote:
> Hmm, has noone in this thread mentioned COAS yet? http://www.coas.org/
Actually, I have. COAS has some drawbacks: it's development is seems
very slow, the mailinglist has no messages except for people complaining
about how to compile it, and it needs all
Antti-Juhani Kaijanaho wrote:
> You just have to design the language to be flexible enough. In this
> post I'll sketch one.
> (datum metoo/foo
> (type yesno)
> (query "Do you want me to do foo?")
> (default yes))
> (if (yes? metoo/foo)
> ((datum metoo/foo2
> (type yesno)
..
You've
Previously Jason Gunthorpe wrote:
> What are you trying to achive? Do you want some sort of tool to pre-scan
> all the .debs, configure them then install?
I want a method to configure packages before unpacking them. If that
involves pre-scanning .deb's, so be it. Doing this is a thing we've wante
Previously Jason Gunthorpe wrote:
> I strongly suspect that if we take a carefull look at what the
> configuration scripts are asking we will find this is not a major hurdle
> for MOST things - and a such should not be the central focus of any
> proposal.
The term "not MOST things" has a tendency
In article <[EMAIL PROTECTED]>,
Antti-Juhani Kaijanaho <[EMAIL PROTECTED]> wrote:
>On Tue, Jul 28, 1998 at 06:53:09PM -0700, Joey Hess wrote:
>> Yes, I understand the distinction. I see the advantages to having a set
>> of questions, rather than a script. But I doubt it will be flexable enough.
>
>
On Tue, Jul 28, 1998 at 06:53:09PM -0700, Joey Hess wrote:
> Yes, I understand the distinction. I see the advantages to having a set
> of questions, rather than a script. But I doubt it will be flexable enough.
You just have to design the language to be flexible enough. In this
post I'll sketch o
On Wed, 29 Jul 1998, Wichert Akkerman wrote:
> Previously Jason Gunthorpe wrote:
> > First, you try not to do that in the postinsts. Look at how M$ forms most
> > of it's configuration and you don't see this. A change of what you want to
> > ask and how you phrase it can likely advoid many of the
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
Previously Jason Gunthorpe wrote:
> First, you try not to do that in the postinsts. Look at how M$ forms most
> of it's configuration and you don't see this. A change of what you want to
> ask and how you phrase it can likely advoid many of these cases.
Look again. Microsoft has gotten very fond o
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
Hi,
I think we may be making the mistake of rushing too soon to
implemetation details; I think we need to consider ideas and visions
that have come up before, and even if they are not implemented
immediately, I would rather we put in some thought so that we have
leeway to implement thi
On Tue, 28 Jul 1998, Joey Hess wrote:
> Yes, I understand the distinction. I see the advantages to having a set
> of questions, rather than a script. But I doubt it will be flexable enough.
> Consider some examples of the questions asked in postinsts now. They often
> go through a tree of possibl
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..
>
> Anyhow, the point is that what
On Tue, 28 Jul 1998, Joey Hess wrote:
> Antti-Juhani Kaijanaho wrote:
> > I like everything about it, except the language. IMO it has the wrong
> > basic assumption, namely that the configuration module controls the
> > frontend like a programmer controls the machine (the language is
> > essenti
Antti-Juhani Kaijanaho wrote:
> I like everything about it, except the language. IMO it has the wrong
> basic assumption, namely that the configuration module controls the
> frontend like a programmer controls the machine (the language is
> essentially astripped-down special-purpose BASIC). I wou
Wichert Akkerman wrote:
> Do you have any comments on my idea for that? I'll qoute it here:
>TEXT is currently defined is a method to add explanatory text to the
>questions. Maybe we should add a command oposite to GO, which says
>"start building a new display, of type (error|message|in
On Wed, Jul 29, 1998 at 12:15:36AM +0200, Wichert Akkerman wrote:
> so we use a simple language where each command is exactly one line. A
> prelimary list of commands is:
I like everything about your proposal
I like everything about it, except the language. IMO it has the wrong
basic assumption,
Previously Joey Hess wrote:
> One other problem I have with the proposal is that it assumes that questions
> will be askedsequentially. But, this means that you won't be able to answer
> a question, go on to the next, and then go back. (Except within a block of
> questions that are all displayed at
Previously Joey Hess wrote:
> I guess I haven't thought the non-interactive frontends through. I was under
> the impression they had to be pre-seeded with data about the questions. If
> they can just return the default to everything (and everything has a sane
> default of course), that handles non-
One other problem I have with the proposal is that it assumes that questions
will be askedsequentially. But, this means that you won't be able to answer
a question, go on to the next, and then go back. (Except within a block of
questions that are all displayed at once of course.) The ability to go
Wichert Akkerman wrote:
> What's wrong with using the non-interactive frontends? Or a non-interactive
> option for normal frontends?
I guess I haven't thought the non-interactive frontends through. I was under
the impression they had to be pre-seeded with data about the questions. If
they can just
Previously Joey Hess wrote:
> This is a great proposal.
Thanks!
> But, it misses some of the stuff Ian Jackson proposed on an earlier thread
> on this subject. He was talking about allowing for completly unattended
> installs, as well as having a way to only see very important questions, etc.
Wh
Wichert Akkerman wrote:
>Configuration Management
This is a great proposal.
But, it misses some of the stuff Ian Jackson proposed on an earlier thread
on this subject. He was talking about allowing for completly unattended
installs, as well as having a way to only see
Configuration Management
Rereading the discussions I realized it might be better to cleanly divide
this text into two sections: managing configuration data, and determining
configuration when installing packages. Hopefully this will result in a
better presentation of
66 matches
Mail list logo
