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


Corinna Vinschen wrote:

> I also found, when setup doesn't have the mount points it doesn't seem
> to be able to take the /etc/setup/installed.db from the path entered as
> root directory.  It installs happily all base packages again a second
> time.
>
> Probably we will still need *some* registry entry.  Setup could create
> one for its own purpose, just to find the installation path.  Maybe the
> registry value should use a version number, so that we can have two
> parallel installation again, should we ever release a -3 distro...

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.

The above is meant to achieve the following objectives:

- the setup tool and other 3rd party tools have a key telling if Cygwin
is installed and where
- at startup setup can find its last-* from the last run and use them as
defaults so that the user doesn't have to re-enter them every time
- installing multiple trees becomes a matter of simply changing the root
dir at step 2 of the install process

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,
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.

- 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?

Brian


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