On Apr 22 02:46, Brian Dessent wrote: > Corinna Vinschen wrote: > > I would suggest to use a setup subkey, because you might find that > > you have to store more than one value at one point. It would be > > cleaner this way, imho. And originally we came up with the version > > number, too, so what about "setup-2" or "setup"? > > Traditionally setup has stored all of its state in files under > /etc/setup. I think this is a good thing to continue, since it makes it > easy to access and manipulate them from scripts. Given that we're > moving the mount table out of the registry and into /etc, I don't see > why we'd want to do the reverse with setup's bits. So in that sense, I > don't see a need for a subkey that will only ever have one key. > > On the other hand, I'd hate for a bad decision now to make things > annoying in the future. Let me ask this: what's the layout for the > other items that will still be in the registry? Are we still looking > at: > > \Software\Cygwin\Program Options\default > \Software\Cygwin\Program Options\foo.exe > \Software\Cygwin\Program Options\bar.exe > \Software\Cygwin\heap_chunk_in_mb > \Software\Cygwin\heap_slop_in_mb > > This is kind of ugly too, we have a mix of things with spaces and > underscores. How about the following: > > \Software\Cygwin\setup\rootdir > \Software\Cygwin\options\heap_chunk_in_mb > \Software\Cygwin\options\heap_slop_in_mb > \Software\Cygwin\options\defaults > \Software\Cygwin\options\app-specific\foo.exe > \Software\Cygwin\options\app-specific\bar.exe > > Or, perhaps: > > \Software\Cygwin\rootdir > \Software\Cygwin\heap_chunk_in_mb > \Software\Cygwin\heap_slop_in_mb > \Software\Cygwin\default_options > \Software\Cygwin\app-specific\foo.exe > \Software\Cygwin\app-specific\bar.exe > > I really don't know.
I don't know either. I'm not going to change what's in Cygwin right now since it's seldomly used anyway. So, for now, let's just agree on \Software\Cygwin\setup\rootdir so I can patch utils/path.cc and upload a new cygwin 1.7.0-4, ok? > (The version number I think is implicit in the fact that this is a > totally new key that's never been used before. If in the very distant > future setup needs yet another namespace it can have a "setup-2" subkey > then.) Fine with me. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
