This is the mail archive of the cygwin-apps 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: [HEADSUP] Let's start a Cygwin 1.7 release area


On Apr 12 16:02, Brian Dessent wrote:
> Here's what I had in mind for the logic:
> 
> On startup, setup looks for $newkey.  If found, it uses the Win32 path
> stored there as the starting value for the root dir/install location. 
> If not found, it looks at $oldkey.  If that's not found, it uses a
> default of c:\cygwin.
> 
> In any case, if the user changes this value on the second step of the
> installer, that new value becomes the effective value immediately;
> anything obtained from the first value should be discarded.  Access to
> files in the POSIX namespace is done purely relative to this root, e.g.
> setup creates an internal mount table of its own that maps the install
> dir to "/" (and for the time being duplicating /{bin,lib} to
> /usr/{bin,lib}, subject to change as well.)  At the end of setup, the
> effective value of the root dir is written out to $newkey.
> Where:
>   newkey = some new key whose location is yet to be decided
>   oldkey = the location corresponding to the root dir of the current
> registry mount table
>
> In both of the above there is the implicit notion of looking first in
> HKLM\Software and then falling back to HKCU\Software if not found,
> allowing the non-admin user to install Cygwin as they please.  The
> location where it was found is used as the starting value for
> justme/allusers, and if the user modifies the setting during the run the
> resulting destination at the end is changed accordingly.

Sounds very reasonable.  The "just me" would only decide about the
setup registry key and the place where the Cygwin desktop shortcut and
menu entries are created.

> Unresolved issues with this plan:
> 
> - What are we going to do about text/binary mode?  To maintain the
> setting, setup would have to be taught to parse/write fstab.  Ugh.  Plan
> B would be to say that if you want textmode you have to edit fstab
> yourself.  That has the advantage of making it harder to use textmode,

I made a quick poll in my neighborhood:

Plan A                                 - 0 votes
Plan B                                 - 1 vote
What the hell are you talking about?   - 7 votes

So I think Plan B is the clear winner.

> which leads to fewer bugreports.  On the other hand, the small army of
> insane people that do actually use textmode will probably be mad that
> they have to manually edit config files (the horror!) because the setup
> tool no longer has a choice.

I'm not exactly concerned.

> - Do we really want to pick a new key for $newkey, or wedge it into the
> same existing location somehow?  I admit that I do find it a bit silly
> that Cygwin still installs under "Cygnus Solutions", and since a 1.7 DLL
> will not even look at the registry I guess it is proper to move to a
> totally new key for this setting.  And of course for the 1.7 testing
> period we'd want it to be separate.  But I mean long term, are we making
> 3rd parties lives easier or harder by having two totally different
> places/formats to check for an existing install of Cygwin?

The registry mount table is supposed to go away.  If you look into the
new postinstall script in the cygwin sources, there's (commented out)
code which reads the old registry keys and converts them to fstab
entries.  I'm planning to use the same code in another script which can
be called by /etc/profile and friends, to create the user specific fstab
file on the fly from the existing registry entries.  What's missing
right now is the code to remove the old registry keys.  But I guess I
will add that, too.

So we're at the point to ask what's the name of the new registry key
should be.  Here's still a problem:  The registry is also used for other
purposes:

  Program Options (Special $CYGWIN settings per application)
  heap_chunk_in_mb
  heap_slop_in_mb

We would need to transfer them to the new place or we stick to the
"Cygnus Solutions" for backward compatibility.  I'm not sure we still
need the Program Options thingy.  I never heard about anybody actually
using heap_slop_in_mb and only fortran programmers seem to need
heap_chunk_in_mb :)

I'm all for changing the name from "Cygnus Solutions" to "Red Hat", but
OTOH I think keeping the name of the key is more hassle free.

I'd suggest to use simply a subkey of the existing Cygwin key:

  {HKLM,HKCU}/Software/Cygnus Solutions/Cygwin/setup-${versioninfo}/

You could use a string value called "install_root" and possibly others
as you see fit since only setup would use them at all.  ${versioninfo}
should probably begin with 2.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat


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