This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: /etc/setup/setup.cfg ?

On Mon, 2003-03-10 at 07:08, Michael A Chase wrote:
> On Sun, 9 Mar 2003 16:38:57 -0000 Max Bowsher <maxb at ukf dot net> wrote:
> > Igor Pechtchanski wrote:
> > > There have been bits of persistent state that people wanted to store
> > > for setup.  I'm proposing an Xdefaults-style setup.cfg in /etc/setup.
> > > If we compile a list of things to go in there, I could write a parser
> > > for it (I don't think it merits yacc, like the one for setup.ini :-D)

weeel :}. If not yacc, then I'm going to want something clean and
extensible. (i.e. you may prefer yacc as a lower hurdle :}). Not that I
love yacc BTW. Perhaps the Interpreter pattern is appropriate, or the
(is there a pattern) common persistence idiom where each object
serialises itself.

Key code requirements:
* Settings must not be centralised in the code.
* GUI must not be a requirement (text mode setup tools already exist).
* Must be robust to handle text/bin issues and users fiddling - OR 100%
opaque to the user. (i.e. if it looks like users can fiddle, we must
survive them fiddling).

> > Ok, but we need to decide: Is this going to be user-edited, or
> > setup-edited?
> > I.e., there is no point in allowing comments, if they get removed every
> > time setup re-writes the file.
> There is probably no harm in allowing comments, just have the first
> one written by setup warn that the file is generated by setup so manual
> changes will be overwritten.

If we have a comment object in the language, it will get inserted in the
outbound file. It's trivial to do that with even a simplistic design. I
don't have a particular opinion on comments myself.

> As for what to do before the mount points are created, what happens
> to the mirror list now if all the user does is download files and
> Cygwin isn't installed locally?

Use the source Luke. 

Now, I have a couple of comments that should be made...

I'm very much pro-this. I've made enough comments about 'when I get
around to... common config' in the archives.

We have two forms of persistent data:
* User driven data (chosen mirrors for example)
* 'System' driven data (what files are in package foo, what official
mirrors exist, timestamps ...)

The requirements I've laid out above apply *only* to the User driven
data. I'll be placing a sanity test regarding that on any patch :}.
System data has somewhat different needs, and we can look at refactoring
the user data framework when we come to tackle system data.

Also, I'd prefer /etc/setup.rc rather that /etc/setup/setup.cfg. 

Finally, I suggest that rather than coding in all the *new* settings one
would like to store, that the existing ones get refactored - and the
migration strategy implemented and tested - and we get that into HEAD. 
An options setting framework that handles the existing persistent UI
choices will handle most anything we want to throw at it.
GPG key available at: <>.

Attachment: signature.asc
Description: This is a digitally signed message part

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]