Re: [HEADSUP] Let's start a Cygwin 1.7 release area

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Charles Wilson]

On Wed, 9 Apr 2008 10:31:39 -0400, Christopher Faylor wrote:
>On Wed, Apr 09, 2008 at 06:09:46AM -0700, Brian Dessent wrote:
>>Corinna Vinschen wrote:
>>>My favorite would be release-2.  It has nothing to do with the DLL
>>
>>Sounds fine to me as well.
>
>It's ok.

Works for me.

One question: the old plan was, as outlined by Brian, that we would
eventually have:

release_legacy   <<-- renamed from existing 'release' directory
release          <<-- new 1.7 stuff, once it is "gold".
(and somewhere we would have a temp release-1.7/-2008/whatever thing,
which would get renamed to 'release')

Is the new plan:

release   <<-- stays exactly as is, forever and ever. (OK, maybe some
pkg updates...)
release-2 <<-- "temp" with custom setup.exe during development, but
eventually becomes "actual" when
  (a) we decide that 1.7 and associated pkgs are ready to go
  (b) and we release a "new" setup.exe with the special "are you
  Win9x"-->release (NOT release_legacy), else -->release-2

That is, no directory renaming at all (which would make the mirrors
happy) -- we "activate" by releasing a new setup?

?

--
Chuck

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Corinna Vinschen]

On Apr  9 11:04, Charles Wilson wrote:
> On Wed, 9 Apr 2008 10:31:39 -0400, Christopher Faylor wrote:
> >On Wed, Apr 09, 2008 at 06:09:46AM -0700, Brian Dessent wrote:
> >>Corinna Vinschen wrote:
> >>>My favorite would be release-2.  It has nothing to do with the DLL
> >>
> >>Sounds fine to me as well.
> >
> >It's ok.
> 
> Works for me.
> 
> One question: the old plan was, as outlined by Brian, that we would
> eventually have:
> 
> release_legacy   <<-- renamed from existing 'release' directory
> release          <<-- new 1.7 stuff, once it is "gold".
> (and somewhere we would have a temp release-1.7/-2008/whatever thing,
> which would get renamed to 'release')
> 
> Is the new plan:
> 
> release   <<-- stays exactly as is, forever and ever. (OK, maybe some
> pkg updates...)
> release-2 <<-- "temp" with custom setup.exe during development, but
> eventually becomes "actual" when
>   (a) we decide that 1.7 and associated pkgs are ready to go
>   (b) and we release a "new" setup.exe with the special "are you
>   Win9x"-->release (NOT release_legacy), else -->release-2
> 
> That is, no directory renaming at all (which would make the mirrors
> happy) -- we "activate" by releasing a new setup?

Yes! :)


Corinna

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

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Corinna Vinschen]

On Jul 25 06:55, Phil Nelson wrote:
> On Friday 25 July 2008 12:21:22 am Corinna Vinschen wrote:
> > No, they aren't.  The reason for this effect is that in 1.5, the user
> > and group ownership, as well as the permissions were ignored by default
> > (CYGWIN=nosmbntsec).
> 
> Thanks.   And are we starting a FAQ for things like this for 1.7?   Such a
> change in the security model between 1.5 and 1.7 is likely to generate
> many questions.

Sure, and I'm three-quarter through the new documentation.  FAQ didn't
see any changes yet.  The current unfinished state of the docs can be
marveled at under http://cygwin.com/1.7/cygwin-ug-net.html


Corinna

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

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Phil Nelson]

[-- Attachment #1: Type: text/plain, Size: 546 bytes --]

On Friday 25 July 2008 12:21:22 am Corinna Vinschen wrote:
> No, they aren't.  The reason for this effect is that in 1.5, the user
> and group ownership, as well as the permissions were ignored by default
> (CYGWIN=nosmbntsec).

Thanks.   And are we starting a FAQ for things like this for 1.7?   Such a
change in the security model between 1.5 and 1.7 is likely to generate
many questions.

--Phil

-- 
Phil Nelson (phil at cs.wwu.edu) http://www.cs.wwu.edu/nelson
NetBSD: http://www.NetBSD.org  Coda: http://www.coda.cs.cmu.edu


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Corinna Vinschen]

On Jul 24 15:40, Phil Nelson wrote:
> 1.5:
> 
>    cd /cygdrive/n
>    ls -ldn JUNK
>    drwxr-xr-x 1 500 513 0 May 27 10:54 JUNK
> 
> 1.7:
> 
>   cd /cygdrive/n
>   ls -ldn JUNK
>   drwxr-x--- 1 4294967295 4294967295 0 Jan 14 2008 JUNK
> 
> So it looks like user, group, permissions and dates are all wrong under 1.7.

No, they aren't.  The reason for this effect is that in 1.5, the user
and group ownership, as well as the permissions were ignored by default
(CYGWIN=nosmbntsec).

With 1.7, CYGWIN=(no)ntsec and CYGWIN=(no)smbntsec are going away in
favor of the "(no)acl" mount option.  acl == ntsec is default.  That
means, you see correct permissions, but the user and group information
(if not backed by a domain controller and bein available in your
Cygwin's /etc/passwd and /etc/group anyway) can't be resolved unless you
have matching user and group entries in /etc/passwd and /etc/group. 

However, there was still a problem up to 1.7.0-18 which results in a
access denied message when trying to create files on a samba share with
"acl" on.  I'm just going to upload 1.7.0-21.  I changed the mkpasswd
and mkgroup tools so that they now allow to create passwd and group
entries for users and groups from Samba servers:

  $ mkpasswd -L samba-machine,100000 -U 0,500-510
  $ mkgroup -L samba-machine,100000 -U 0,users

These commands will create entries from the global user list on the
Samba machine (-L machinename).  The local created uids will be mapped
with an offset of 100000.  Additionally, it will create entries for the
standard UNIX accounts on the Samba machine for the users with uids 0
and 500-510.  Same for the groups with uid 0 and name "users".  The
standard UNIX accounts are the ones you see in the Windows security
tab as "Unix User\foouser" and "Unix Group\foogroup".

If that's all too complicated for you, use the mount option noacl
for this drive.


HTH,
Corinna

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

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Christopher Faylor]

On Thu, Jul 24, 2008 at 03:40:51PM -0700, Phil Nelson wrote:
>On Wednesday 02 April 2008 5:35:51 am Corinna Vinschen wrote:
>> Having said that, I would like to ask especially you package maintainers
>> to set up a separate machine or a separate cygwin directory for the 1.7
>> release. 
>
>Well, I'm a little slow on following and I'm not an official maintainer (yet) but
>I am the maintainer of the Coda distribution for Windows that uses cygwin
>heavily.   (In fact, I do have a set of sources that build cygwin packages that
>we currently distribute via a "private mirror".   I've just not done the work
>to do a GTG e-mail.   Part of the reason is that one of the packages, the
>kernel module for Coda, requires a Windows build environment to be installed
>even though the kernel module is compiled from a UNIX makefile ... so
>once the extra build environments are installed, one can do "make; make install"
>in the cygwin directory tree.... but I digress...)
>
>I decided to try 1.7 with Coda and rather quickly got stopped by a user/group issue
>in 1.7.   I have my primary sources copies on a NetBSD box with Samba running on it.
>Works great from 1.5.   Map the drive in windows, use cygwin to compile via the 
>net.    In 1.7 the user and group returned is 2^32-1 (ffffffff) which doesn't allow me
>to do anything other than read on the file server.
>
>I'm not sure if this is the right list for 1.7 bugs or if they should go to another list.
>If I'm wrong, I'm sure someone will tell me....
>
>e.g. to the same file server and ls the same 
>
>1.5:
>
>   cd /cygdrive/n
>   ls -ldn JUNK
>   drwxr-xr-x 1 500 513 0 May 27 10:54 JUNK
>
>1.7:
>
>  cd /cygdrive/n
>  ls -ldn JUNK
>  drwxr-x--- 1 4294967295 4294967295 0 Jan 14 2008 JUNK
>
>So it looks like user, group, permissions and dates are all wrong under 1.7.

It could look like that when you look at it from 100 yards away.  To get
closer we'd need to see things like what your /etc/passwd and /etc/group
files look like.  Even cygcheck output would help.

cgf

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Phil Nelson]

[-- Attachment #1: Type: text/plain, Size: 1910 bytes --]

On Wednesday 02 April 2008 5:35:51 am Corinna Vinschen wrote:
> Having said that, I would like to ask especially you package maintainers
> to set up a separate machine or a separate cygwin directory for the 1.7
> release. 

Well, I'm a little slow on following and I'm not an official maintainer (yet) but
I am the maintainer of the Coda distribution for Windows that uses cygwin
heavily.   (In fact, I do have a set of sources that build cygwin packages that
we currently distribute via a "private mirror".   I've just not done the work
to do a GTG e-mail.   Part of the reason is that one of the packages, the
kernel module for Coda, requires a Windows build environment to be installed
even though the kernel module is compiled from a UNIX makefile ... so
once the extra build environments are installed, one can do "make; make install"
in the cygwin directory tree.... but I digress...)

I decided to try 1.7 with Coda and rather quickly got stopped by a user/group issue
in 1.7.   I have my primary sources copies on a NetBSD box with Samba running on it.
Works great from 1.5.   Map the drive in windows, use cygwin to compile via the 
net.    In 1.7 the user and group returned is 2^32-1 (ffffffff) which doesn't allow me
to do anything other than read on the file server.

I'm not sure if this is the right list for 1.7 bugs or if they should go to another list.
If I'm wrong, I'm sure someone will tell me....

e.g. to the same file server and ls the same 

1.5:

   cd /cygdrive/n
   ls -ldn JUNK
   drwxr-xr-x 1 500 513 0 May 27 10:54 JUNK

1.7:

  cd /cygdrive/n
  ls -ldn JUNK
  drwxr-x--- 1 4294967295 4294967295 0 Jan 14 2008 JUNK

So it looks like user, group, permissions and dates are all wrong under 1.7.

--Phil

-- 
Phil Nelson (phil at cs.wwu.edu) http://www.cs.wwu.edu/nelson
NetBSD: http://www.NetBSD.org  Coda: http://www.coda.cs.cmu.edu


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Corinna Vinschen]

On Apr 22 18:00, Corinna Vinschen wrote:
> On Apr 22 11:51, Charles Wilson wrote:
> > Brian Dessent wrote:
> > > the DLL already supports
> > > parallel installs by the fact that it uses /etc/fstab.
> > 
> > Only in very limited cases:
> > [...]
> > Right?  You still have to worry about the shared memory region name, and
> > its format which may vary with DLL version. Plus there still might be
> > other stuff that prevents parallel cygwin installs from running
> > simultaneously.  And I don't think supporting simultaneous use of
> > multiple cygwin installations is one of our goals, is it?
> 
> In theory, the latest incarnation of the Cygwin DLL should work 
> in parallel with a 1.5.x DLL.  In theory.  I didn't actually test it.

Now I did.  I installed the 1.7 release first, a few days ago, into
C:\cygwin.  My first step installing 1.5 was to rename C:\cygwin to
C:\somethingelse.  Then I removed the registry keys
"HKCU\Software\Cygnus Solutions" and "HKLM\SOFTWARE\Cygnus Solutions"
and installed 1.5 into a directory called C:\cygwin-1.5.  Finally I
renamed C:\somethingelse back to  C:\cygwin.

I'm just running a 1.5 and a 1.7 shell concurrently and both are alive
and healthy.  None of them know from each other, they have separate
process lists, separate /proc dirs, separate everything.

Just this note: Don't mix processes started from the 1.5 and 1.7
installations within the same shell.  Keep 1.5 and 1.7 process trees
separate.  You have been warned.


Corinna

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

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Pēteris Kļaviņš]

Brian Dessent wrote:
>> So why can't the registry entry be <path-to-dll> instead of the fixed
>> 'setup\rootdir' in order that the setup application could populate a
>> drop-down list of all currently installed Cygwins?
> 
> It could.

Excellent.  I second your suggestion.  :-)

> But I think Chuck made a good point that the ability to have
> multiple installed copies extends to what you might call "expert users",
> i.e. they must know the ins and outs of not actually ever using these
> two installs at once.  And so we need to be careful not to give the
> impression that this is supposed to work in the general case.

Sigh.  Yes I read Chuck's clear denouncement that there is any whisper 
of there being a goal to support multiple Cygwin DLL's running 
simultaneously.  However, that doesn't stop me from lobbying for setting 
up such a goal, and having a <path-to-dll> registry entry for the Cygwin 
DLL would be a step towards it, even if in the short term there was only 
one such path allowed in the registry, i.e., subsequent Cygwin setups 
would remove the previous path and replace it with the current user's
choice, if it was different.
------------------------------------------------------------------------
  Peter Klavins

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Brian Dessent]

P?teris K?avi?š wrote:

> So why can't the registry entry be <path-to-dll> instead of the fixed
> 'setup\rootdir' in order that the setup application could populate a
> drop-down list of all currently installed Cygwins?

It could.  But I think Chuck made a good point that the ability to have
multiple installed copies extends to what you might call "expert users",
i.e. they must know the ins and outs of not actually ever using these
two installs at once.  And so we need to be careful not to give the
impression that this is supposed to work in the general case.

> Maybe all cyg*.exe native Windows applications could use this same
> algorithm to compute their root.

cygcheck and strace are the only things that use the code in question,
and strace only uses it for the purpose of resolving the win32 filename
of the output file specified with -o.

> Would this problem go away if cygrunsrv.exe used the same algorithm to
> compute its root?

No, the problem is that the operating system's service configuration in
the registry needs the path to cygrunsrv.exe -- it needs to know the
path to the image to execute, and we of course have no control over
that.  The only workaround I can think of to providing an absolute path
would be to use the REG_EXPAND_SZ key type's capability to expand
variables from the environment, e.g. %CygwinRoot%\bin\cygrunsrv.exe. 
However, this doesn't really solve anything, it just shifts the problem
to making sure this variable is set.  And even if you figured out a way
to do that, the change in environment would not take effect in the
services.exe process until the next time it was started, i.e. a reboot. 
It would still be easier just to edit the service config after moving
the files.

> I have (finally) started using an environment where I share all my
> personal files on a separate disk drive accessible from all my bootable
> operating systems, whether it's Vista, WS2008, or Debian.  The drive
> names (and mount points) vary.  It's the same as moving install trees,
> and it would be nice if Cygwin didn't really care that when I started
> the services this time they were started from a different location than
> last time.

In this case the problem has nothing to do with any code in Cygwin.  But
no I don't see your situation as the same, since as long as the location
is consistent on any given system, you can install the service once and
it will continue to be correct from there on.

Brian

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Pēteris Kļaviņš]

Brian Dessent wrote:
> P?teris K?avi?Å¡ wrote:
> 
> So that when you run setup it can start out with the same root that you
> last used so that you don't have to type it in every time.
> 
> That, and also so that the native tools like cygcheck can locate the
> root dir.

So why can't the registry entry be <path-to-dll> instead of the fixed 
'setup\rootdir' in order that the setup application could populate a 
drop-down list of all currently installed Cygwins?

> This will be a minor problem in that if you had two installs,
> both cygchecks will think the root is the last one that you updated with
> setup.  Corinna, perhaps cygcheck needs to compute the root relative to
> its location like the DLL instead.  This means cygcheck will always have
> to be in /bin, but I think that's fine; it's not like it has ever been
> anywhere else.

Maybe all cyg*.exe native Windows applications could use this same 
algorithm to compute their root.

> Manually moving an installed cygwin tree would be a silly thing to do,
> it would break all your services for example.

Would this problem go away if cygrunsrv.exe used the same algorithm to 
compute its root?

> Anyway, if someone were
> silly enough to do that they would just need to enter the new location
> in setup; but this will be the case whether or not setup remembers its
> last install root, so I don't see how this is pertinent.

I have (finally) started using an environment where I share all my 
personal files on a separate disk drive accessible from all my bootable 
operating systems, whether it's Vista, WS2008, or Debian.  The drive 
names (and mount points) vary.  It's the same as moving install trees, 
and it would be nice if Cygwin didn't really care that when I started 
the services this time they were started from a different location than 
last time.

[In any case, Brian, I appreciate your time in answering my off-beat 
questions and realise that they aren't 'core' to the business of getting 
Cygwin to work.  Sooner or later I'll put together the correct build 
environment, something which has eluded me as yet, to produce some 
diff's of ideas I have, rather than just talk about them.]
------------------------------------------------------------------------
  Peter Klavins

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Charles Wilson]

On Tue, 22 Apr 2008 09:07:34 -0700, "Brian Dessent" said:
> Charles Wilson wrote:
> 
> > (1) we're talking about cygwin-1.7.x
> > (2) Either
> >     (a) only one of those parallel instances is in use at a time,
> >     including installed services,
> >     or
> >     (b) all of those parallel instances have exactly the same version of
> >     the DLL
> 
> Right, I don't think anyone is talking about having two trees in use
> simultaneously.

I just didn't want somebody searching the archives to think cygwin-1.7
officially supported lots of different cygwin1.dlls scattered all over
the filesystem, all in use at the same time. It doesn't.

> > (3) Even so, doing this is not officially supported (the current
> > dual-installation "support" vis-a-vis cygwin-1.5.x and cygwin-1.7.x is
> >     (a) temporary and
> >     (b) intended for package maintainers only, in order to prepare the
> >     cygwin-1.7 packages -- and package maintainers generally know what
> >     they are doing and what the pitfalls of a dual/multiple installation
> >     are.
> 
> At the moment this is quite experimental, yes; but I don't see any
> reason why it would be a temporary arrangement.  Once we get the changes
> in setup.exe and 1.7 released, it will still be possible to keep
> multiple parallel installs by just changing the root dir in setup to
> select which one to install/update.  Why would we want to prevent that
> from working?  Isn't this one of the desired payoffs of moving the mount
> table out of the registry in the first place?

I didn't say we would *break* it. There's a difference between "it
happens to work" and "is a supported configuration". During the buildup
to 1.7.0-release, it's going to be a de-facto "supported" configuration
-- if there are problems, they'll need to be fixed so that maintainers
can build 1.7 packages.  (Although Corinna recommended using completely
separate (possibly virtual) machines for 1.5 and 1.7).

After that, it's probably caveat emptor.  Right now, we can tell a user
to run 'cygcheck -s -v -r' and point to "multiple cygwin dll's" and tell
'em to fix that first, PERIOD, unless they really know what they are
doing.  After the official 1.7.0 rollout, unless we really truly
actually support simultaneous *use* of multiple cygwin trees -- which we
do not and will not -- I don't want to support/debug/handhold multiple
simultaneous *installations* of cygwin, either.

Because it's way too easy to slide from simultaneous installation to
simultaneous use unless you are very careful.  During the transition, we
*will* run into that problem -- but maintainers can be trusted to
usually figure those problems out on their own.

--
Chuck

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Brian Dessent]

Charles Wilson wrote:

> (1) we're talking about cygwin-1.7.x
> (2) Either
>     (a) only one of those parallel instances is in use at a time,
>     including installed services,
>     or
>     (b) all of those parallel instances have exactly the same version of
>     the DLL

Right, I don't think anyone is talking about having two trees in use
simultaneously.

> (3) Even so, doing this is not officially supported (the current
> dual-installation "support" vis-a-vis cygwin-1.5.x and cygwin-1.7.x is
>     (a) temporary and
>     (b) intended for package maintainers only, in order to prepare the
>     cygwin-1.7 packages -- and package maintainers generally know what
>     they are doing and what the pitfalls of a dual/multiple installation
>     are.

At the moment this is quite experimental, yes; but I don't see any
reason why it would be a temporary arrangement.  Once we get the changes
in setup.exe and 1.7 released, it will still be possible to keep
multiple parallel installs by just changing the root dir in setup to
select which one to install/update.  Why would we want to prevent that
from working?  Isn't this one of the desired payoffs of moving the mount
table out of the registry in the first place?

Brian

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Corinna Vinschen]

On Apr 22 11:51, Charles Wilson wrote:
> Brian Dessent wrote:
> > the DLL already supports
> > parallel installs by the fact that it uses /etc/fstab.
> 
> Only in very limited cases:
> 
> (1) we're talking about cygwin-1.7.x
> (2) Either 
>     (a) only one of those parallel instances is in use at a time,
>     including installed services,
>     or
>     (b) all of those parallel instances have exactly the same version of
>     the DLL
> (3) Even so, doing this is not officially supported (the current
> dual-installation "support" vis-a-vis cygwin-1.5.x and cygwin-1.7.x is 
>     (a) temporary and
>     (b) intended for package maintainers only, in order to prepare the
>     cygwin-1.7 packages -- and package maintainers generally know what
>     they are doing and what the pitfalls of a dual/multiple installation
>     are.
> 
> Right?  You still have to worry about the shared memory region name, and
> its format which may vary with DLL version. Plus there still might be
> other stuff that prevents parallel cygwin installs from running
> simultaneously.  And I don't think supporting simultaneous use of
> multiple cygwin installations is one of our goals, is it?

In theory, the latest incarnation of the Cygwin DLL should work 
in parallel with a 1.5.x DLL.  In theory.  I didn't actually test it.


Corinna

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

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Charles Wilson]

Brian Dessent wrote:
> the DLL already supports
> parallel installs by the fact that it uses /etc/fstab.

Only in very limited cases:

(1) we're talking about cygwin-1.7.x
(2) Either 
    (a) only one of those parallel instances is in use at a time,
    including installed services,
    or
    (b) all of those parallel instances have exactly the same version of
    the DLL
(3) Even so, doing this is not officially supported (the current
dual-installation "support" vis-a-vis cygwin-1.5.x and cygwin-1.7.x is 
    (a) temporary and
    (b) intended for package maintainers only, in order to prepare the
    cygwin-1.7 packages -- and package maintainers generally know what
    they are doing and what the pitfalls of a dual/multiple installation
    are.

Right?  You still have to worry about the shared memory region name, and
its format which may vary with DLL version. Plus there still might be
other stuff that prevents parallel cygwin installs from running
simultaneously.  And I don't think supporting simultaneous use of
multiple cygwin installations is one of our goals, is it?

--
Chuck

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Brian Dessent]

P?teris K?avi?š wrote:

> Hmm.  Well, if it's only setup that needs the registry entry, and if
> multiple setups, regardless of <path-to-setup>, are using the same fixed
> registry entry serially, what's the point of the registry entry?

So that when you run setup it can start out with the same root that you
last used so that you don't have to type it in every time.

> Remembering where the last setup's root was?

That, and also so that the native tools like cygcheck can locate the
root dir.  This will be a minor problem in that if you had two installs,
both cygchecks will think the root is the last one that you updated with
setup.  Corinna, perhaps cygcheck needs to compute the root relative to
its location like the DLL instead.  This means cygcheck will always have
to be in /bin, but I think that's fine; it's not like it has ever been
anywhere else.

> Which could have been moved by the user afterwards?

Manually moving an installed cygwin tree would be a silly thing to do,
it would break all your services for example.  Anyway, if someone were
silly enough to do that they would just need to enter the new location
in setup; but this will be the case whether or not setup remembers its
last install root, so I don't see how this is pertinent.

Brian

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Corinna Vinschen]

On Apr 22 04:07, Brian Dessent wrote:
> Corinna Vinschen wrote:
> 
> > 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?
> 
> Okay, let's go with that.

I've checked in the patch and uploaded a new 1.7.0-4 package to the
release-2 area.  Maybe trhat helps for testing setup, too.


Corinna

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

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Pēteris Kļaviņš]

Brian Dessent wrote:
> P?teris K?avi?Å¡ wrote:
> 
>> Does the Cygwin DLL know its own path?  If so, how about
>>
>> \Software\Cygwin\<path-to-dll>
>>
>> ... to allow multiple parallel Cygwin installs?
> 
> I think you've missed the context of this discussion.  This key will
> never be read or written by the DLL, and the DLL already supports
> parallel installs by the fact that it uses /etc/fstab.
> 

Hmm.  Well, if it's only setup that needs the registry entry, and if 
multiple setups, regardless of <path-to-setup>, are using the same fixed 
registry entry serially, what's the point of the registry entry? 
Remembering where the last setup's root was?  Which could have been 
moved by the user afterwards?
------------------------------------------------------------------------
  Peter Klavins

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Brian Dessent]

P?teris K?avi?š wrote:

> Does the Cygwin DLL know its own path?  If so, how about
> 
> \Software\Cygwin\<path-to-dll>
> 
> ... to allow multiple parallel Cygwin installs?

I think you've missed the context of this discussion.  This key will
never be read or written by the DLL, and the DLL already supports
parallel installs by the fact that it uses /etc/fstab.

Brian

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Pēteris Kļaviņš]

Brian Dessent wrote:
> Corinna Vinschen wrote:
> 
>> 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?

Does the Cygwin DLL know its own path?  If so, how about

\Software\Cygwin\<path-to-dll>

... to allow multiple parallel Cygwin installs?
------------------------------------------------------------------------
  Peter Klavins

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Corinna Vinschen]

On Apr 22 01:25, Brian Dessent wrote:
> I suppose I didn't state my point very well.  Yes, there are Cygwin
> tools for manipulating the registry.  But the registry is an
> implementation detail, and you should not need to know anything about
> registry keys to uninstall Cygwin.  At the moment this can be
> accomplished via "umount -A" (and "cygrunsrv -R") with zero knowledge of
> where the mount table happens to be implemented, or that there even is a
> registry.
> 
> With the mount table no longer stored in the registry, we will have no
> way around saying "you must remove such-and-such key from the
> registry."  This is bad, IMHO.
> 
> A separate issue is that even if we document a proper procedure for
> removing Cygwin (as we currently do in the FAQ), users often don't read
> manuals and just plunge in and try to delete stuff.  They fail because
> they forgot to stop services first, or because they don't understand
> file ACLs.  By adding a new key in the registry we make it increasingly
> likely that in their fervor to dive in and delete things without reading
> docs they will miss yet another step.  I want to finally solve this for
> good by making a program that encapsulates all this knowledge so that
> they don't have to RTFM, and so that they just have a nice thing to
> click on like every other well-behaved Windows program.  I think it's
> been a requested feature more than once.

Btw., I think that an uninstall option would be a good thing.

While I talked about the cyglsa DLL in my reply to Chuck on the Cygwin
ML, it occured to me that this would be a job for the uninstaller as well:

If the cyglsa DLL has been added to the registry value

  HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Authentication Packages

it's not possible to remove the DLL unless you reboot.  So, what the
uninstaller would have to do is to remove the substring which contains
"cyglsa.dll" or "cyglsa64.dll" from the above registry value and then
to add the DLL to the PendingFileRenameOperations registry value.


Corinna

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

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Brian Dessent]

Corinna Vinschen wrote:

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

Okay, let's go with that.

Brian

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Corinna Vinschen]

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

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Brian Dessent]

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.

(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.)

Brian

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Corinna Vinschen]

On Apr 21 23:02, Brian Dessent wrote:
> Corinna Vinschen wrote:
> 
> > it just occured to me that I need the exact key name which setup will
> > use to store the root directory of the installation.  I nedd it to get
> > cygcheck working, even if it's not installed into the same path as the
> > Cygwin DLL.
> > 
> >   "{HKLM,HKCU}\Software\Cygwin\???"
> > 
> > ??? = "Setup\root" maybe?  Or with a version number?
> 
> A good question.  I haven't implemented anything yet, so we can choose
> whatever we want.  I wonder if it's really necessary to have a whole
> subkey for this since at the moment there is only the one value that
> setup will read.  How about simply "\Software\Cygwin\rootdir"?

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

Anyway, it's your decision.  I will go with whatever you think is
approriate.  I just need to know so I can fix utils/path.cc.


Corinna

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

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Brian Dessent]

Jörg Schaible wrote:

> > That reminds me of something... I've always been a bit annoyed that
> > people always resort to manually editing the registry to
> > remove Cygwin,
> > when umount is the documented and preferred method.  But now, we will
> > have no such utility to suggest and so to remove Cygwin the
> > user will be
> > forced to use regedit.
> 
> regtool remove {HKLM,HKCU}\Software\Cygwin\???

I suppose I didn't state my point very well.  Yes, there are Cygwin
tools for manipulating the registry.  But the registry is an
implementation detail, and you should not need to know anything about
registry keys to uninstall Cygwin.  At the moment this can be
accomplished via "umount -A" (and "cygrunsrv -R") with zero knowledge of
where the mount table happens to be implemented, or that there even is a
registry.

With the mount table no longer stored in the registry, we will have no
way around saying "you must remove such-and-such key from the
registry."  This is bad, IMHO.

A separate issue is that even if we document a proper procedure for
removing Cygwin (as we currently do in the FAQ), users often don't read
manuals and just plunge in and try to delete stuff.  They fail because
they forgot to stop services first, or because they don't understand
file ACLs.  By adding a new key in the registry we make it increasingly
likely that in their fervor to dive in and delete things without reading
docs they will miss yet another step.  I want to finally solve this for
good by making a program that encapsulates all this knowledge so that
they don't have to RTFM, and so that they just have a nice thing to
click on like every other well-behaved Windows program.  I think it's
been a requested feature more than once.

Brian

RE: [HEADSUP] Let's start a Cygwin 1.7 release area

[Jörg Schaible]

cygwin-apps-owner@cygwin.com wrote:
> Corinna Vinschen wrote:
> 
>> it just occured to me that I need the exact key name which setup will
>> use to store the root directory of the installation.  I nedd it to
>> get cygcheck working, even if it's not installed into the same path
>> as the Cygwin DLL. 
>> 
>>   "{HKLM,HKCU}\Software\Cygwin\???"
>> 
>> ??? = "Setup\root" maybe?  Or with a version number?
> 
> A good question.  I haven't implemented anything yet, so we can choose
> whatever we want.  I wonder if it's really necessary to have a whole
> subkey for this since at the moment there is only the one value that
> setup will read.  How about simply "\Software\Cygwin\rootdir"?
> 
> That reminds me of something... I've always been a bit annoyed that
> people always resort to manually editing the registry to
> remove Cygwin,
> when umount is the documented and preferred method.  But now, we will
> have no such utility to suggest and so to remove Cygwin the
> user will be
> forced to use regedit.

regtool remove {HKLM,HKCU}\Software\Cygwin\???

>  Combined with the fact that most
> users trip over
> the fact that sometimes ACLs on files like /var/log/sshd.log require
> them to take ownership before deleting, I would like to be
> able to offer
> an uninstaller.  This would handle checking for running
> Cygwin processes
> and prompting to exit them (or terminating them), stopping and
> uninstalling all Cygwin services, deleting the entire Cygwin tree,
> removing start menu and desktop icons, removing everything from the
> registry, and whatever else is necessary.  It would be the nuclear
> option, deleting without remorse all traces with one click; I think
> users want this.  It would of course be a standalone MinGW app like
> setup.exe, except that it would get installed somewhere in
> the tree, and
> added to the add/remove applet.  Anyway, SHTDI and everything
> but I just
> want to float the idea to gauge response.

Guess, it's nevertheless a good idea ...

- Jörg

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Brian Dessent]

Corinna Vinschen wrote:

> it just occured to me that I need the exact key name which setup will
> use to store the root directory of the installation.  I nedd it to get
> cygcheck working, even if it's not installed into the same path as the
> Cygwin DLL.
> 
>   "{HKLM,HKCU}\Software\Cygwin\???"
> 
> ??? = "Setup\root" maybe?  Or with a version number?

A good question.  I haven't implemented anything yet, so we can choose
whatever we want.  I wonder if it's really necessary to have a whole
subkey for this since at the moment there is only the one value that
setup will read.  How about simply "\Software\Cygwin\rootdir"?

That reminds me of something... I've always been a bit annoyed that
people always resort to manually editing the registry to remove Cygwin,
when umount is the documented and preferred method.  But now, we will
have no such utility to suggest and so to remove Cygwin the user will be
forced to use regedit.  Combined with the fact that most users trip over
the fact that sometimes ACLs on files like /var/log/sshd.log require
them to take ownership before deleting, I would like to be able to offer
an uninstaller.  This would handle checking for running Cygwin processes
and prompting to exit them (or terminating them), stopping and
uninstalling all Cygwin services, deleting the entire Cygwin tree,
removing start menu and desktop icons, removing everything from the
registry, and whatever else is necessary.  It would be the nuclear
option, deleting without remorse all traces with one click; I think
users want this.  It would of course be a standalone MinGW app like
setup.exe, except that it would get installed somewhere in the tree, and
added to the add/remove applet.  Anyway, SHTDI and everything but I just
want to float the idea to gauge response.

Brian

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Christopher Faylor]

On Mon, Apr 21, 2008 at 10:34:12PM +0200, Corinna Vinschen wrote:
>On Apr 21 10:33, Corinna Vinschen wrote:
>> On Apr 20 11:45, Christopher Faylor wrote:
>> > Since most of what I did was automated, I probably ended up deleting too
>> > much.  Please take a look at the package directories that you maintain
>> > and verify that the release-2 directory contains something that makes
>> > sense.
>> 
>> My packages seem to be fine.
>
>However, there was something wrong with the cygwin package directory.
>An ls shows a 1.5.19-4 binary package with no sources and a binary and
>source package version "1.7-1", which never existed before.

Both were just my playing with the cygwin directory.

cgf

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Corinna Vinschen]

On Apr 21 10:33, Corinna Vinschen wrote:
> On Apr 20 11:45, Christopher Faylor wrote:
> > Since most of what I did was automated, I probably ended up deleting too
> > much.  Please take a look at the package directories that you maintain
> > and verify that the release-2 directory contains something that makes
> > sense.
> 
> My packages seem to be fine.

However, there was something wrong with the cygwin package directory.
An ls shows a 1.5.19-4 binary package with no sources and a binary and
source package version "1.7-1", which never existed before.

Also, even though the directory permissions are 2775, and even though I'm
in group "cygwin" as the directorie's group, I can't add or remove files.
I had to do that as root. 

For some reason, I had to delete the cygwin-1.5.19-4.tar.bz2 file twice.
I got no error message the first time, but owner and group were changed
from "root.root" to "cyguser.cygwin".  The second rm actually deleted the
file.  Are you sure we can trust this unionfs implementation?  It seems
a bit unfinshed.


Corinna

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

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Corinna Vinschen]

Brian,

On Apr 21 19:48, Corinna Vinschen wrote:
> On Apr 21 16:04, Corinna Vinschen wrote:
> > On Apr 16 10:44, Corinna Vinschen wrote:
> > > On Apr 15 19:28, Brian Dessent wrote:
> > > >   So, with that in
> > > > mind, are there any objections to simply HK{LM,CU}\Software\Cygwin?
> > > 
> > > Just go ahead.
> > 
> > I did now.  I just checked in a change which
> > 
> > - drops reading mount points from the registry entirely,
> > 
> > - let the postinstall script (which still should be moved to its own
> >   package) create /etc/fstab entries from the old system registry
> >   mount points.
> > 
> > - Sets the Cygwin parent registry keys to HKLM\Software\Cygwin and
> >   HKCU\Software\Cygwin.
> > 
> > I guess now the way is free for setup.exe to utilize the new registry
> > locations as well.
> 
> Btw., just FYI, utils/path.cc doesn't build right now since it still
> tries to pull mount points from the registry.  I'm working on changing
> that to utilizing fstab files instead.

it just occured to me that I need the exact key name which setup will
use to store the root directory of the installation.  I nedd it to get
cygcheck working, even if it's not installed into the same path as the
Cygwin DLL.

  "{HKLM,HKCU}\Software\Cygwin\???"

??? = "Setup\root" maybe?  Or with a version number?

Corinna

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

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Corinna Vinschen]

On Apr 21 16:04, Corinna Vinschen wrote:
> On Apr 16 10:44, Corinna Vinschen wrote:
> > On Apr 15 19:28, Brian Dessent wrote:
> > >   So, with that in
> > > mind, are there any objections to simply HK{LM,CU}\Software\Cygwin?
> > 
> > Just go ahead.
> 
> I did now.  I just checked in a change which
> 
> - drops reading mount points from the registry entirely,
> 
> - let the postinstall script (which still should be moved to its own
>   package) create /etc/fstab entries from the old system registry
>   mount points.
> 
> - Sets the Cygwin parent registry keys to HKLM\Software\Cygwin and
>   HKCU\Software\Cygwin.
> 
> I guess now the way is free for setup.exe to utilize the new registry
> locations as well.

Btw., just FYI, utils/path.cc doesn't build right now since it still
tries to pull mount points from the registry.  I'm working on changing
that to utilizing fstab files instead.


Corinna

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

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Corinna Vinschen]

On Apr 16 10:44, Corinna Vinschen wrote:
> On Apr 15 19:28, Brian Dessent wrote:
> >   So, with that in
> > mind, are there any objections to simply HK{LM,CU}\Software\Cygwin?
> 
> Just go ahead.

I did now.  I just checked in a change which

- drops reading mount points from the registry entirely,

- let the postinstall script (which still should be moved to its own
  package) create /etc/fstab entries from the old system registry
  mount points.

- Sets the Cygwin parent registry keys to HKLM\Software\Cygwin and
  HKCU\Software\Cygwin.

I guess now the way is free for setup.exe to utilize the new registry
locations as well.


Corinna

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

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Corinna Vinschen]

On Apr 20 11:45, Christopher Faylor wrote:
> Since most of what I did was automated, I probably ended up deleting too
> much.  Please take a look at the package directories that you maintain
> and verify that the release-2 directory contains something that makes
> sense.

My packages seem to be fine.


Thanks,
Corinna

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

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Charles Wilson]

Christopher Faylor wrote:
> I think I recreated the area complete with your changes.  Let me know if
> I screwed anything up.

Nope, all my changes are still there.  The weird behavior with 'find' is 
still there, too. :-(

> This making changes to an area which is actively being rsynced and
> potentially being worked on is nerve-wracking.

<g>

--
Chuck

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Christopher Faylor]

On Sun, Apr 20, 2008 at 06:43:35PM -0400, Charles Wilson wrote:
> Christopher Faylor wrote:
>>Please hold off making any changes to anything in the release-2 area.
>>I want to try another unionfs implementation which doesn't seem to have
>>this problem.
>
>Whoops.
>
>Don't worry, you can blow away my changes.  I've got a handy email that
>lists all the changes I made.  <g>

I think I recreated the area complete with your changes.  Let me know if
I screwed anything up.

This making changes to an area which is actively being rsynced and
potentially being worked on is nerve-wracking.

cgf

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Charles Wilson]

Christopher Faylor wrote:

> Please hold off making any changes to anything in the release-2 area.
> I want to try another unionfs implementation which doesn't seem to have
> this problem.

Whoops.

Don't worry, you can blow away my changes. I've got a handy email that 
lists all the changes I made. <g>

--
Chuck

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Charles Wilson]

Christopher Faylor wrote:
> I think the simplest thing to do is remove the test from setup.hint.  It's
> all test anyway.  Anyone who is using this should be extremely aware of
> the fact that it's unstable.

OK.

Changes I made in the release-2 area:

1) inetutils: made test release 1.5-3 current

2) libtool: made test release 2.2.2-2 current; removed versioned 
requires (made global). Removed libltdl3 from requires.

3) libltdl3: copied over old libtool-1.5.27a-1-src package as 
libltdl3-1.5.27a-1-src, and removed external-source: line from 
libltdl3's setup.hint.

4) login: made test release 1.9-8 current

5) pkg-config: made test release 0.23a-1 current

6) rxvt: removed reference to non-existent prev: version

7) tcp_wrappers: removed reference to non-existent prev: version, and 
versioned requires (made global).
7a) libwrap0: removed versioned requires (made global).
7b) libwrap-devel: removed versioned requires (made global).


I did not remove the xpm-nox package, but maybe we should. It has been 
superseded by the libXpm-noX package for years. The old package provides
    cygXpm-noX4.dll
while the new package (built using libtool) provides
    cygXpm-noX-4.dll
There are no packages in either the release or release-2 areas that rely 
on the old package.

This is odd, tho:

$ pwd
.../pub/cygwin/release
$ find . -name "setup.hint" | grep libXpm-noX
./libXpm-noX/setup.hint
./libXpm-noX/libXpm-noX-devel/setup.hint
./libXpm-noX/libXpm-noX_4/setup.hint
$ cd ../release-2
$ pwd
.../pub/cygwin/release-2
$ find . -name "setup.hint" | grep libXpm-noX
$ ls libXpm-noX/setup.hint
libXpm-noX/setup.hint
$ ls libXpm-noX/libXpm-noX-devel/setup.hint
libXpm-noX/libXpm-noX-devel/setup.hint
$ ls libXpm-noX/libXpm-noX_4/setup.hint
libXpm-noX/libXpm-noX_4/setup.hint

Huh?


Here's a list of setup.hint files in the release-2 area that have test:, 
priv:, or curr: specifiers -- but given the weirdness above, I'm not 
sure it is comprehensive.

$ find . -name "setup.hint" |\
    xargs grep -l -E 'test:|curr:|prev:' |\
    sort | uniq | sed -e 's/^\.\///'

emacs/emacs-el/setup.hint
emacs/emacs-X11/setup.hint
emacs/setup.hint
gdb/setup.hint
grace/setup.hint
postgresql/libecpg-compat2/setup.hint
postgresql/libpq3/setup.hint
postgresql/setup.hint
xemacs/setup.hint
xemacs/xemacs-emacs-common/setup.hint
xemacs/xemacs-tags/setup.hint

> Apparently there is a bug in this version of unionfs, though.  If you
> try to recreate a missing file by just copying it in or touching it you
> get a "File exists" error and that's not right.  You aren't supposed to
> have to know that there is something special going on and a mysterious
> error like that sort of breaks that assumption.

So how does this work in the future? If I have upload a new package to 
the (old) release area, it will also appear in the release-2 area?

If I edit the setup.hint in the (old) release area, those changes will 
show up in the release-2 area, UNLESS I or someone else has already 
modified the release-2 setup.hint?

(and don't delete anything from the release-2 area unless you're really 
really sure you'll never want to put it back <g>)

--
Chuck

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Christopher Faylor]

On Sun, Apr 20, 2008 at 05:56:17PM -0400, Christopher Faylor wrote:
>Apparently there is a bug in this version of unionfs, though.  If you
>try to recreate a missing file by just copying it in or touching it you
>get a "File exists" error and that's not right.  You aren't supposed to
>have to know that there is something special going on and a mysterious
>error like that sort of breaks that assumption.

Please hold off making any changes to anything in the release-2 area.
I want to try another unionfs implementation which doesn't seem to have
this problem.

cgf

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Christopher Faylor]

On Sun, Apr 20, 2008 at 02:46:28PM -0400, Charles Wilson wrote:
> Christopher Faylor wrote:
>> Since most of what I did was automated, I probably ended up deleting too
>> much.  Please take a look at the package directories that you maintain
>> and verify that the release-2 directory contains something that makes
>> sense.
>
> If we find a problem, how should we fix it? For instance, release(1) 
> inetutils has prev: 1.3.2-37, curr: 1.3.2-40, and test: 1.5-3. release-2 
> has only 1.5-3, but its setup still specified that 1.5-3 is test (it also 
> specifies the non-existant 1.3.2-40 and 1.3.2-37 packages as curr: and 
> prev:, respectively).
>
> I'm not ready to make inetutils-1.5-3 curr: on the release(1) side. 
> However, since ALL of release-2 is test:, I could see doing any of the 
> following:
>
> (1) copy over the 1.3.2-40 packages, and remove the prev: entry from 
> setup.hint
>
> (2) change the release-2 setup.hint so that on "that side", inetutils-1.5-3 
> becomes curr: (and remove all references in setup.hint to the "missing" 
> packages).
>
> (3) change the release-2 setup.hint by removing all references to the 
> "missing" packages, but otherwise leave things along. That is, on the 
> release-2 side, "inetutils" would ONLY be available as a test release, 
> until I manually promote 1.5-3.
>
> But I'm not really sure how union fs works. Can I edit setup.hint in place? 
> Can I "copy" back the "missing" files, or is there some special procedure 
> that makes them "re-appear"?

I think the simplest thing to do is remove the test from setup.hint.  It's
all test anyway.  Anyone who is using this should be extremely aware of
the fact that it's unstable.

Apparently there is a bug in this version of unionfs, though.  If you
try to recreate a missing file by just copying it in or touching it you
get a "File exists" error and that's not right.  You aren't supposed to
have to know that there is something special going on and a mysterious
error like that sort of breaks that assumption.

cgf

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Charles Wilson]

Christopher Faylor wrote:
> Since most of what I did was automated, I probably ended up deleting too
> much.  Please take a look at the package directories that you maintain
> and verify that the release-2 directory contains something that makes
> sense.

If we find a problem, how should we fix it? For instance, release(1) 
inetutils has prev: 1.3.2-37, curr: 1.3.2-40, and test: 1.5-3. 
release-2 has only 1.5-3, but its setup still specified that 1.5-3 is 
test (it also specifies the non-existant 1.3.2-40 and 1.3.2-37 packages 
as curr: and prev:, respectively).

I'm not ready to make inetutils-1.5-3 curr: on the release(1) side. 
However, since ALL of release-2 is test:, I could see doing any of the 
following:

(1) copy over the 1.3.2-40 packages, and remove the prev: entry from 
setup.hint

(2) change the release-2 setup.hint so that on "that side", 
inetutils-1.5-3 becomes curr: (and remove all references in setup.hint 
to the "missing" packages).

(3) change the release-2 setup.hint by removing all references to the 
"missing" packages, but otherwise leave things along. That is, on the 
release-2 side, "inetutils" would ONLY be available as a test release, 
until I manually promote 1.5-3.

But I'm not really sure how union fs works. Can I edit setup.hint in 
place? Can I "copy" back the "missing" files, or is there some special 
procedure that makes them "re-appear"?

--
Chuck

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Christopher Faylor]

On Wed, Apr 16, 2008 at 12:24:46PM -0400, Christopher Faylor wrote:
>On Wed, Apr 16, 2008 at 11:39:16AM +0200, Corinna Vinschen wrote:
>>On Apr 15 20:51, Lapo Luchini wrote:
>>> PS: my only WinXP box is still waiting for his motherboard back from RMA... 
>>> I'll try qemu to test cygwin-1.7 and, if it's not too slow, produce updated 
>>> packages for both 1.5 and 1.7 (or is 1.7 "near enough" that is better to 
>>> update that first?).
>>
>>We will not make 1.7 an official release for some time.  For the official
>>release, please stick to 1.5.  You can create update packages for 1.7
>>for your local installation, but let's wait a couple of days uploading
>>1.7 packages until Chris changed the release area to use unionfs.
>
>I played around a little more with this and found some problems that I
>have to investigate.  When I move a file into the area from another
>directory it gives an error.  That isn't really a big deal but I don't
>like putting things into production with known problems unless I have a
>vague understanding of the problem.  So it will be a couple more days
>before I have the time to track this down.
>
>The size of this new, purged area is: 1926596K bytes.
>
>(I fixed my purge script)

The new directory has been set up.  release-2 is a union file system with
the standard cygwin release as a read-only component of the directory.  I
removed the _obsolete directory, and should have removed everything which
was in the obsolete Category.  I've indiscriminately purged any package which
sorted lexically less (using the upset version sort algorithm) than what
seemed to be the most recent package.

Since most of what I did was automated, I probably ended up deleting too
much.  Please take a look at the package directories that you maintain
and verify that the release-2 directory contains something that makes
sense.

cgf

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Christopher Faylor]

On Wed, Apr 16, 2008 at 11:39:16AM +0200, Corinna Vinschen wrote:
>On Apr 15 20:51, Lapo Luchini wrote:
>> PS: my only WinXP box is still waiting for his motherboard back from RMA... 
>> I'll try qemu to test cygwin-1.7 and, if it's not too slow, produce updated 
>> packages for both 1.5 and 1.7 (or is 1.7 "near enough" that is better to 
>> update that first?).
>
>We will not make 1.7 an official release for some time.  For the official
>release, please stick to 1.5.  You can create update packages for 1.7
>for your local installation, but let's wait a couple of days uploading
>1.7 packages until Chris changed the release area to use unionfs.

I played around a little more with this and found some problems that I
have to investigate.  When I move a file into the area from another
directory it gives an error.  That isn't really a big deal but I don't
like putting things into production with known problems unless I have a
vague understanding of the problem.  So it will be a couple more days
before I have the time to track this down.

The size of this new, purged area is: 1926596K bytes.

(I fixed my purge script)

cgf

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Corinna Vinschen]

On Apr 15 20:51, Lapo Luchini wrote:
> PS: my only WinXP box is still waiting for his motherboard back from RMA... 
> I'll try qemu to test cygwin-1.7 and, if it's not too slow, produce updated 
> packages for both 1.5 and 1.7 (or is 1.7 "near enough" that is better to 
> update that first?).

We will not make 1.7 an official release for some time.  For the official
release, please stick to 1.5.  You can create update packages for 1.7
for your local installation, but let's wait a couple of days uploading
1.7 packages until Chris changed the release area to use unionfs.


Thanks,
Corinna

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

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Corinna Vinschen]

On Apr 15 19:28, Brian Dessent wrote:
>   So, with that in
> mind, are there any objections to simply HK{LM,CU}\Software\Cygwin?

Just go ahead.


Corinna

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

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Brian Dessent]

Eric Blake wrote:

> I hate unnecessary spaces.  Can we go with "Cygwin" rather than "Cygwin
> Project", so that scripts using /proc/registry don't have to worry about
> the space?

The only reason I suggested "Cygwin Project\Cygwin" is that it's
supposed to be a two level hierarchy, company\product, matching the
current "Cygnus Solutions\Cygwin" arrangement.

However, after a quick jaunt through HKLM\Software on this machine I see
that there are a good number of programs that forego the two level
custom and just put keys under HKLM\Software\Foo.  So, with that in
mind, are there any objections to simply HK{LM,CU}\Software\Cygwin?

Brian

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Corinna Vinschen on 4/15/2008 12:38 PM:
|
| Since everybody else seems to dislike the company name in the registry
| key, I will not further argue against using "Cygwin Project\Cygwin" or
| just "Cygwin".

I hate unnecessary spaces.  Can we go with "Cygwin" rather than "Cygwin
Project", so that scripts using /proc/registry don't have to worry about
the space?

- --
Don't work too hard, make some time for fun as well!

Eric Blake             ebb9@byu.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkgE+y0ACgkQ84KuGfSFAYByzgCcDyXFFF9/0lgFJjUD6kNt0UJK
/gEAniAU01A0w3WdNHYy5eKPraNzoL2Q
=kfbj
-----END PGP SIGNATURE-----

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Lapo Luchini]

Corinna Vinschen wrote:
> I will not further argue against using "Cygwin Project\Cygwin" or
> just "Cygwin".
>   

I guess the one name no one can strongly argue against is the one we're 
using right now: "perfect" or "outdated" as it may be, it has at least 
one reason to be (retro-compatibility).

PS: my only WinXP box is still waiting for his motherboard back from 
RMA... I'll try qemu to test cygwin-1.7 and, if it's not too slow, 
produce updated packages for both 1.5 and 1.7 (or is 1.7 "near enough" 
that is better to update that first?).

-- 
Lapo Luchini
lapo@lapo.it (OpenPGP & X.509)
www.lapo.it (Jabber, ICQ, MSN)

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Corinna Vinschen]

On Apr 15 13:59, Christopher Faylor wrote:
> On Tue, Apr 15, 2008 at 05:44:00PM +0200, Corinna Vinschen wrote:
> >Red Hat *is* the owner of the code, regardless of the registry key you
> >want to use.  I know that you have mixed feelings about Red Hat,
> >however, assuming the code is owned by the FSF, would you object
> >against a parent key name of FSF as well?
> 
> Ok, since my motives for having an opinion are in question, I will
> withdraw from the discussion, rather than spending time on
> pointless self-justification.

I apologize for making this argument.  It was needless, pointless and
rude.

Since everybody else seems to dislike the company name in the registry
key, I will not further argue against using "Cygwin Project\Cygwin" or
just "Cygwin".


Corinna

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

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Christopher Faylor]

On Tue, Apr 15, 2008 at 05:44:00PM +0200, Corinna Vinschen wrote:
>On Apr 15 10:17, Christopher Faylor wrote:
>>On Tue, Apr 15, 2008 at 11:08:49AM +0200, Corinna Vinschen wrote:
>>>Having said that, should we really rename the registry keys, what do we
>>>do with the "Program Options" and the two "heap_foo" values?
>>
>>I'd like to keep the "Program Options" and nuke the "heap_foo" options.
>
>Maybe you can get rid of heap_chunk_in_mb but it's still not clear that
>we can get rid of heap_slop_in_mb.  The strange allocation in 2003 and
>later is a problem and just because we had nobody complaining for a
>while doesn't mean the current slop value is always sufficient.  I'm
>for keeping this option.
>
>>I also object to using "Red Hat" as the "owner" [...]
>
>Red Hat *is* the owner of the code, regardless of the registry key you
>want to use.  I know that you have mixed feelings about Red Hat,
>however, assuming the code is owned by the FSF, would you object
>against a parent key name of FSF as well?

Ok, since my motives for having an opinion are in question, I will
withdraw from the discussion, rather than spending time on
pointless self-justification.

cgf

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Reini Urban]

2008/4/15, Corinna Vinschen:
> On Apr 15 10:17, Christopher Faylor wrote:
>  > I also object to using "Red Hat" as the "owner" [...]
>
>  Red Hat *is* the owner of the code, regardless of the registry key you
>  want to use.  I know that you have mixed feelings about Red Hat,
>  however, assuming the code is owned by the FSF, would you object against
>  a parent key name of FSF as well?

Cannot we just use just "Cygwin" as the most obvious choice.
We really don't have to use some artificial company name.
-- 
Reini

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Corinna Vinschen]

On Apr 15 10:17, Christopher Faylor wrote:
> On Tue, Apr 15, 2008 at 11:08:49AM +0200, Corinna Vinschen wrote:
> >Having said that, should we really rename the registry keys, what do we
> >do with the "Program Options" and the two "heap_foo" values?
> 
> I'd like to keep the "Program Options" and nuke the "heap_foo" options.

Maybe you can get rid of heap_chunk_in_mb but it's still not clear that
we can get rid of heap_slop_in_mb.  The strange allocation in 2003 and
later is a problem and just because we had nobody complaining for a
while doesn't mean the current slop value is always sufficient.  I'm for
keeping this option.

> I also object to using "Red Hat" as the "owner" [...]

Red Hat *is* the owner of the code, regardless of the registry key you
want to use.  I know that you have mixed feelings about Red Hat,
however, assuming the code is owned by the FSF, would you object against
a parent key name of FSF as well?


Corinna

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

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Christopher Faylor]

On Tue, Apr 15, 2008 at 11:08:49AM +0200, Corinna Vinschen wrote:
>On Apr 15 10:55, Corinna Vinschen wrote:
>> On Apr 14 20:02, Brian Dessent wrote:
>>>Christopher Faylor wrote:
>>>>Yes, I know.  I just don't think it clarifies anything to put a "Red
>>>>Hat" in the registry.
>>>
>>>I was thinking "Cygwin" would be better as well, but since it is
>>>supposed to be a two-level heirarchy how about
>>>"HK{LM,CU}\Software\Cygwin Project\Cygwin".  It has always seemed to me
>>>that we actively try to de-emphasize any association that Red Hat has
>>>in the actual day-to-day operation of the project, other than owning
>>>the copyrights and having their own commercial fork.  Likewise with the
>>
>>Well, not exactly.  I have done a lot of my 1.7 development lately on
>>blessed Red Hat time.  The IPv6 changes and the long path name support
>>wouldn't be as progressed as they are if I hadn't got enough paid time
>>to do them.  I don't think that deserves to be ignored.
>
>Having said that, should we really rename the registry keys, what do we
>do with the "Program Options" and the two "heap_foo" values?

I'd like to keep the "Program Options" and nuke the "heap_foo" options.

I also object to using "Red Hat" as the "owner" regardless of how much
paid work you've been able to do.  I think it sends an extremely mixed
message for the public Cygwin project to be viewed as "owned" by Red Hat
while we solicit donations to help with development on the Cygwin web
site.  I've been paid by a few companies to work on Cygwin and have been
spent long hours tracking down bugs for them.  Additionally, most of the
work I have done for Cygwin in the past was done in my spare time even
when I was a paid employee

While I realize that you've spent quite a bit more time being paid by
Red Hat to make ipv6 and long path names work, I don't think that
necessarily translates into using Red Hat as the owner key in the
registry.

Also, given that this is a Windows project I have to wonder just how
much Red Hat would desire to have their names in the Windows Registry.

cgf

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Corinna Vinschen]

On Apr 15 11:31, Corinna Vinschen wrote:
> On Apr 15 02:29, Brian Dessent wrote:
> > Corinna Vinschen wrote:
> > 
> > > Having said that, should we really rename the registry keys, what do we
> > > do with the "Program Options" and the two "heap_foo" values?  Should
> > > they be moved to the new registry key?  If yes, should the postinstall
> > > script I created a couple of days ago also move them?
> > 
> > For the heap_chunk settings, couldn't they simply be moved into $CYGWIN?
> 
> Unfortunately, no.  The environment initialization requires that the
> memory initialization has already be done.

Of course, what we could do is to create a ../etc/cygwin.conf file which
is read when the first cygwin process starts...


Corinna

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Corinna Vinschen]

On Apr 15 02:29, Brian Dessent wrote:
> Corinna Vinschen wrote:
> 
> > Having said that, should we really rename the registry keys, what do we
> > do with the "Program Options" and the two "heap_foo" values?  Should
> > they be moved to the new registry key?  If yes, should the postinstall
> > script I created a couple of days ago also move them?
> 
> For the heap_chunk settings, couldn't they simply be moved into $CYGWIN?

Unfortunately, no.  The environment initialization requires that the
memory initialization has already be done.


Corinna

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

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Brian Dessent]

Corinna Vinschen wrote:

> Having said that, should we really rename the registry keys, what do we
> do with the "Program Options" and the two "heap_foo" values?  Should
> they be moved to the new registry key?  If yes, should the postinstall
> script I created a couple of days ago also move them?

For the heap_chunk settings, couldn't they simply be moved into $CYGWIN?

Brian

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Corinna Vinschen]

On Apr 15 10:55, Corinna Vinschen wrote:
> On Apr 14 20:02, Brian Dessent wrote:
> > Christopher Faylor wrote:
> > 
> > > Yes, I know.  I just don't think it clarifies anything to put a "Red
> > > Hat" in the registry.
> > 
> > I was thinking "Cygwin" would be better as well, but since it is
> > supposed to be a two-level heirarchy how about
> > "HK{LM,CU}\Software\Cygwin Project\Cygwin".  It has always seemed to me
> > that we actively try to de-emphasize any association that Red Hat has in
> > the actual day-to-day operation of the project, other than owning the
> > copyrights and having their own commercial fork.  Likewise with the
> 
> Well, not exactly.  I have done a lot of my 1.7 development lately on
> blessed Red Hat time.  The IPv6 changes and the long path name support
> wouldn't be as progressed as they are if I hadn't got enough paid time
> to do them.  I don't think that deserves to be ignored.

Having said that, should we really rename the registry keys, what do we
do with the "Program Options" and the two "heap_foo" values?  Should
they be moved to the new registry key?  If yes, should the postinstall
script I created a couple of days ago also move them?

Btw., I think the postinstall script as part of the Cygwin package was a
bad idea.  I will create another package called "base-cygwin" which will
contain this script as well as a few scripts in /bin which allow users
to resurrect their HKCU keys and values.


Corinna

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

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Corinna Vinschen]

On Apr 14 19:24, Igor Peshansky wrote:
> Hmm.  Even now, one does not have to edit the registry to switch from
> binary mode to text mode -- you just need to re-mount with the appropriate
> option.  I assume the same will hold for the /etc/fstab approach.

No, how should it?  Of course you have to edit the fstab file to
create a text mount from a binary mount, *iff* you want a persistent
solution.  mount(1) only creates temporary mount points who's life
time is determined by the life time of the Cygwin processes in the
current session.

> If we taught mount to do this now and removed the "Text" option from setup
> altogether, complainers could be directed to the mount manpage.  Then
> switching to the new setup won't be that much of a pain (at least in the
> text/binary department).

They will be directed to the user's guide.


Corinna

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

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Corinna Vinschen]

On Apr 14 20:02, Brian Dessent wrote:
> Christopher Faylor wrote:
> 
> > Yes, I know.  I just don't think it clarifies anything to put a "Red
> > Hat" in the registry.
> 
> I was thinking "Cygwin" would be better as well, but since it is
> supposed to be a two-level heirarchy how about
> "HK{LM,CU}\Software\Cygwin Project\Cygwin".  It has always seemed to me
> that we actively try to de-emphasize any association that Red Hat has in
> the actual day-to-day operation of the project, other than owning the
> copyrights and having their own commercial fork.  Likewise with the

Well, not exactly.  I have done a lot of my 1.7 development lately on
blessed Red Hat time.  The IPv6 changes and the long path name support
wouldn't be as progressed as they are if I hadn't got enough paid time
to do them.  I don't think that deserves to be ignored.


Corinna

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

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Brian Dessent]

Igor Peshansky wrote:

> But one thing to consider is that by adding a registry key, we're setting
> things up for one dominant installation of Cygwin.  So people juggling
> multiple installations really *will* have to go edit the registry to
> switch -- no more nice "mount -m" approach, since the mounts will no
> longer apply anyway.

Can you clarify what you mean here?  I don't understand.  You're talking
about maintaining separate installs, but part of the plan for setup.exe
that I outlined supports this directly by the fact that if you change
the value of the root install dir at step 2, setup then forgets anything
it knew about the previous value, enabling you to keep around as many
parallel installs as you want.

Or do you mean keeping around an old-style 1.5 tree and a new-style 1.7
tree simultaneously?  In that case you'd be using the old setup.exe
(which doesn't know a thing about $newkey) for the 1.5 tree so I still
don't see any conflict.  Where does the need to edit the registry
manually arise?

Brian

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Brian Dessent]

Christopher Faylor wrote:

> Yes, I know.  I just don't think it clarifies anything to put a "Red
> Hat" in the registry.

I was thinking "Cygwin" would be better as well, but since it is
supposed to be a two-level heirarchy how about
"HK{LM,CU}\Software\Cygwin Project\Cygwin".  It has always seemed to me
that we actively try to de-emphasize any association that Red Hat has in
the actual day-to-day operation of the project, other than owning the
copyrights and having their own commercial fork.  Likewise with the
"Company ID" in the resource strings for cygwin1.dll, listing Red Hat
always seemed a bit off to me, but I recognise that if we have to list a
real company that Red Hat is the obvious choice.

Brian

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Igor Peshansky]

On Sat, 12 Apr 2008, Brian Dessent wrote:

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

Hmm.  Even now, one does not have to edit the registry to switch from
binary mode to text mode -- you just need to re-mount with the appropriate
option.  I assume the same will hold for the /etc/fstab approach.  It
might make it easier if mount understood absolute POSIX paths as well
(i.e., "mount -t /etc/text /etc/text" should work).

If we taught mount to do this now and removed the "Text" option from setup
altogether, complainers could be directed to the mount manpage.  Then
switching to the new setup won't be that much of a pain (at least in the
text/binary department).

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

I agree that naming the new key "Cygnus Solutions" is silly, beyond
certain nostalgic value.

But one thing to consider is that by adding a registry key, we're setting
things up for one dominant installation of Cygwin.  So people juggling
multiple installations really *will* have to go edit the registry to
switch -- no more nice "mount -m" approach, since the mounts will no
longer apply anyway.

Also, things like heap_chunk_in_mb currently live in the registry.  Will
they stay there?  Will we instead have /etc/cygwinopts (or move it to
$CYGWIN)?
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_	    pechtcha@cs.nyu.edu | igor@watson.ibm.com
ZZZzz /,`.-'`'    -.  ;-;;,_		Igor Peshansky, Ph.D. (name changed!)
     |,4-  ) )-,_. ,\ (  `'-'		old name: Igor Pechtchanski
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"That which is hateful to you, do not do to your neighbor.  That is the whole
Torah; the rest is commentary.  Go and study it." -- Rabbi Hillel

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Christopher Faylor]

On Mon, Apr 14, 2008 at 11:56:28AM +0200, Corinna Vinschen wrote:
>On Apr 13 15:35, Christopher Faylor wrote:
>> On Sun, Apr 13, 2008 at 11:42:46AM +0200, Corinna Vinschen wrote:
>> >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 use Program Options (since I invented it) but I'm probably the only
>> person in the known universe to do so.
>
>Are you suggesting to remove the Program Options?  I admit I never quite
>understood what to do with them which I couldn't put into a script.

?  "Program Options" are not intended to be put in a script.  They are
intended to be set once to cygwin environment variable settings and then
forgotten.  It's somewhat equivalent to setting a global cygwin
environment variable and could be used to set a per-system or per-user
policy.

>>>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.
>>
>>Can't it just be "Cygwin" rather than "Cygnus Solutions" or "Red Hat"?
>
>By definition the key under the Software key is supposed to be the
>company name, the next key is the product key, os it should contain the
>"Red Hat" *iff* we change it.  I'm not sure, though, we should change
>it at all.

Yes, I know.  I just don't think it clarifies anything to put a "Red
Hat" in the registry.

cgf

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Corinna Vinschen]

On Apr 13 15:35, Christopher Faylor wrote:
> On Sun, Apr 13, 2008 at 11:42:46AM +0200, Corinna Vinschen wrote:
> >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 use Program Options (since I invented it) but I'm probably the only
> person in the known universe to do so.

Are you suggesting to remove the Program Options?  I admit I never quite
understood what to do with them which I couldn't put into a script.

> >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.
> 
> Can't it just be "Cygwin" rather than "Cygnus Solutions" or "Red Hat"?

By definition the key under the Software key is supposed to be the
company name, the next key is the product key, os it should contain the
"Red Hat" *iff* we change it.  I'm not sure, though, we should change it
at all.


Corinna

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

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Christopher Faylor]

On Sun, Apr 13, 2008 at 11:04:42AM +0200, Corinna Vinschen wrote:
>On Apr 13 00:44, Christopher Faylor wrote:
>> I added setup-2.ini creation to the Makefile which creates setup.ini.
>> 
>> (and commented out the cron entry that you had which was also doing
>> this)
>
>Thanks, I removed the crontab entry entirely.

I had to tweak this further because the two runs were stomping on each
other changing the packages directory back and forth between release and
release-2.  So, I've created a 'packages-2' directory which can be used
to search for packages in the -2 directory and modified upset to optionally
generate this directory.

cgf

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Christopher Faylor]

On Sun, Apr 13, 2008 at 11:03:14AM +0200, Corinna Vinschen wrote:
>On Apr 12 23:43, Christopher Faylor wrote:
>> On Fri, Apr 11, 2008 at 05:13:33PM +0200, Corinna Vinschen wrote:
>> >I've now created a release-2 area.  I used a somewhat intermediary
>> >approach.  The dirs are real dirs, the tar.bz2 files are symlinks
>> >to the release area, the setup.hint and md5.sum files are copies.
>> >The cygwin subdir only contains 1.7.0-1 packages.
>> >
>> >Chris, could you please set up another upset which creates the
>> >corresponding setup-2.{bz2,ini} files?
>> 
>> I have another way to do this using a union fs.  Using a union fs means
>> that we can have a cygwin-2 directory which mirrors the old cygwin
>> directory, gaining the benefits of hardlinking, but also allowing
>> removals in the new directory without affecting the old cygwin
>> directory.
>> [...]
>> The only downside to this is that the mirrors will apparently be copying
>> all of the data twice.
>
>That's what I was trying to avoid.  In the long run you will have
>two separate areas but the load of the mirroring is stretched out
>over time.  Probably I'm just still living in modem times...
>
>> all of the data twice.  So, we could remove all of the obsolete files
>> and older revisions from this new release directory to minimize the
>> extra copying.
>
>That might help a lot.  If every package dir only contains the latest
>versions you would have less than half the size.  The only problem
>would be that you have to grep the setup.hint files and remove
>potential version information.

Actually the difference is 3122332 purged vs. 4640060 unpurged.

I am not sure how much to worry about the effect on the mirrors.  It
seems like there would be an additional flurry of activity that would
eventually just die down.  I hate to make supportability decisions based
on external constraints.

That does raise the issue of the mirror checking software that runs to
make sure that a mirror is valid.  It seems like that may need to be
tweaked no matter what we do.

cgf

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Christopher Faylor]

On Sun, Apr 13, 2008 at 11:42:46AM +0200, Corinna Vinschen wrote:
>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 use Program Options (since I invented it) but I'm probably the only
person in the known universe to do so.

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

Can't it just be "Cygwin" rather than "Cygnus Solutions" or "Red Hat"?

cgf

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Corinna Vinschen]

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

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Corinna Vinschen]

On Apr 13 00:44, Christopher Faylor wrote:
> I added setup-2.ini creation to the Makefile which creates setup.ini.
> 
> (and commented out the cron entry that you had which was also doing
> this)

Thanks, I removed the crontab entry entirely.

Corinna

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

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Corinna Vinschen]

On Apr 12 23:43, Christopher Faylor wrote:
> On Fri, Apr 11, 2008 at 05:13:33PM +0200, Corinna Vinschen wrote:
> >I've now created a release-2 area.  I used a somewhat intermediary
> >approach.  The dirs are real dirs, the tar.bz2 files are symlinks
> >to the release area, the setup.hint and md5.sum files are copies.
> >The cygwin subdir only contains 1.7.0-1 packages.
> >
> >Chris, could you please set up another upset which creates the
> >corresponding setup-2.{bz2,ini} files?
> 
> I have another way to do this using a union fs.  Using a union fs means
> that we can have a cygwin-2 directory which mirrors the old cygwin
> directory, gaining the benefits of hardlinking, but also allowing
> removals in the new directory without affecting the old cygwin
> directory.
> [...]
> The only downside to this is that the mirrors will apparently be copying
> all of the data twice.

That's what I was trying to avoid.  In the long run you will have
two separate areas but the load of the mirroring is stretched out
over time.  Probably I'm just still living in modem times...

> all of the data twice.  So, we could remove all of the obsolete files
> and older revisions from this new release directory to minimize the
> extra copying.

That might help a lot.  If every package dir only contains the latest
versions you would have less than half the size.  The only problem
would be that you have to grep the setup.hint files and remove
potential version information.


Corinna

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

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Christopher Faylor]

On Fri, Apr 11, 2008 at 05:13:33PM +0200, Corinna Vinschen wrote:
>On Apr  9 18:28, Corinna Vinschen wrote:
>> On Apr  9 10:31, Christopher Faylor wrote:
>> > On Wed, Apr 09, 2008 at 06:09:46AM -0700, Brian Dessent wrote:
>> > >Corinna Vinschen wrote:
>> > >>My favorite would be release-2.  It has nothing to do with the DLL
>> > >
>> > >Sounds fine to me as well.
>> > 
>> > It's ok.
>> 
>> Oh, btw., can we really just use symlinks to the top-level dirs?
>> It just occured to me that some package directories contain
>> subdirectories for packages which are maintained by another
>> maintainer.  For instance the perl and python subdirs...
>
>I've now created a release-2 area.  I used a somewhat intermediary
>approach.  The dirs are real dirs, the tar.bz2 files are symlinks
>to the release area, the setup.hint and md5.sum files are copies.
>The cygwin subdir only contains 1.7.0-1 packages.
>
>Chris, could you please set up another upset which creates the
>corresponding setup-2.{bz2,ini} files?

I added setup-2.ini creation to the Makefile which creates setup.ini.

(and commented out the cron entry that you had which was also doing
this)

cgf

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Christopher Faylor]

On Fri, Apr 11, 2008 at 05:13:33PM +0200, Corinna Vinschen wrote:
>On Apr  9 18:28, Corinna Vinschen wrote:
>> On Apr  9 10:31, Christopher Faylor wrote:
>> > On Wed, Apr 09, 2008 at 06:09:46AM -0700, Brian Dessent wrote:
>> > >Corinna Vinschen wrote:
>> > >>My favorite would be release-2.  It has nothing to do with the DLL
>> > >
>> > >Sounds fine to me as well.
>> > 
>> > It's ok.
>> 
>> Oh, btw., can we really just use symlinks to the top-level dirs?
>> It just occured to me that some package directories contain
>> subdirectories for packages which are maintained by another
>> maintainer.  For instance the perl and python subdirs...
>
>I've now created a release-2 area.  I used a somewhat intermediary
>approach.  The dirs are real dirs, the tar.bz2 files are symlinks
>to the release area, the setup.hint and md5.sum files are copies.
>The cygwin subdir only contains 1.7.0-1 packages.
>
>Chris, could you please set up another upset which creates the
>corresponding setup-2.{bz2,ini} files?

I have another way to do this using a union fs.  Using a union fs means
that we can have a cygwin-2 directory which mirrors the old cygwin
directory, gaining the benefits of hardlinking, but also allowing
removals in the new directory without affecting the old cygwin
directory.

I set up a release-2008 directory briefly under
/sourceware/ftp/anonftp/pub/cygwin where I've removed all of the
cygwin-1.5* files from the cygwin directory, left the existing
setup.hint, and put cygwin-1.7* files there.  The directory now contains
the actual setup.hint from /sourceware/ftp/anonftp/pub/cygwin and
the new files that are unique.

The only downside to this is that the mirrors will apparently be copying
all of the data twice.  So, we could remove all of the obsolete files
and older revisions from this new release directory to minimize the
extra copying.

I've always wanted to use a union fs and I think that, except for the
hit on the mirrors, this is going to be the most problem free way of
maintaining a separate build area.

cgf

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Brian Dessent]

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

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Corinna Vinschen on 4/12/2008 9:15 AM:
|
| Probably we will still need *some* registry entry.  Setup could create
| one for its own purpose, just to find the installation path.

I agree.  Besides, based on the question on the main list - how is an
independent distributor supposed to know if cygwin is installed, so they
don't become a 3PP?  If we have something in the registry, the answer is
obvious - cygwin is installed.  If we don't, then they have to hunt for
likely candidate locations (and will probably guess wrong, becoming a 3PP
even though they were trying to play nice and search for a previous
installation).

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

I think we need a version number, and a directory where the installation
was done.  But we don't need a full mount table.  And I think it is still
conceivable that cygwin1.dll does not have to refer to the registry, just
setup.exe.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             ebb9@byu.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkgA9TkACgkQ84KuGfSFAYBX5ACdEHk5SV36EMLHxw1rQCfNwPo8
xZkAoIA1a0pDIBkN9D6/cKLeCxCN6AQc
=x7b6
-----END PGP SIGNATURE-----

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Corinna Vinschen]

On Apr 12 05:45, Brian Dessent wrote:
> Corinna Vinschen wrote:
> 
> > When I start setup-1.7, it seems to find the already existing c:/cygwin
> > installation.  Even though I choose "C:/cygwin-2" as installation path,
> > the new setup-2.ini content is compared against the already existing
> > installation.  The result is that setup-1.7 offers to install only
> > the single changed package:  cygwin itself.
> 
> Right, it reads /etc/setup/installed.db (where /etc is derived from the
> mount table) to see what the current versions are.
> 
> > Why is setup using the information from the existing installation
> > even if I choose to install into another directory?  Is it because
> > the mount points in the registry are looked at?  That's not correct
> > anymore, given that the registry mount points are not used for the
> > new installation anyway.
> > 
> > Is it possible to change setup so that it ignores the registry mount
> > points?  And it must nort write new ones either, btw...
> 
> Oh.  Teaching it not to read or write to the mount table in the registry
> is going to be a lot more work than just telling it to read a different
> .ini file.  I'll see what I can do, but until then I think we'll just
> have to tell people to do the switching manually (mount -m/umount -A).

Thank you.

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


Corinna

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

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Brian Dessent]

Corinna Vinschen wrote:

> When I start setup-1.7, it seems to find the already existing c:/cygwin
> installation.  Even though I choose "C:/cygwin-2" as installation path,
> the new setup-2.ini content is compared against the already existing
> installation.  The result is that setup-1.7 offers to install only
> the single changed package:  cygwin itself.

Right, it reads /etc/setup/installed.db (where /etc is derived from the
mount table) to see what the current versions are.

> Why is setup using the information from the existing installation
> even if I choose to install into another directory?  Is it because
> the mount points in the registry are looked at?  That's not correct
> anymore, given that the registry mount points are not used for the
> new installation anyway.
> 
> Is it possible to change setup so that it ignores the registry mount
> points?  And it must nort write new ones either, btw...

Oh.  Teaching it not to read or write to the mount table in the registry
is going to be a lot more work than just telling it to read a different
.ini file.  I'll see what I can do, but until then I think we'll just
have to tell people to do the switching manually (mount -m/umount -A).

Brian

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Corinna Vinschen]

On Apr 12 14:23, Dr. Volker Zell wrote:
> >>>>> Corinna Vinschen writes:
> 
>     > I guess we'll wait a day until this all settles on the mirrors and
>     > then I'll create an announcement for the developers and package
>     > maintainers.
> 
> An updated maintainerlist would also be handy ...

http://cygwin.com/cygwin-pkg-maint


Corinna

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

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Dr. Volker Zell]

>>>>> Corinna Vinschen writes:

    > I guess we'll wait a day until this all settles on the mirrors and
    > then I'll create an announcement for the developers and package
    > maintainers.

An updated maintainerlist would also be handy ...

    > Thanks,
    > Corinna

Ciao
  Volker

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Corinna Vinschen]

On Apr 12 13:35, Corinna Vinschen wrote:
> On Apr 11 18:47, Brian Dessent wrote:
> > Corinna Vinschen wrote:
> > 
> > > Brian, could you please prepare a temporary setup-1.7.exe which
> > > only downloads from the release-2 area?
> > 
> > Okay, I uploaded <http://cygwin.com/setup-1.7.exe> which fetches
> > setup-2.{ini,bz2}.  It identifies itself as version 2.590-1.7special on
> > the splash page so that we can tell it apart from the normal.
> 
> Cool, thanks!  I've set up a cronjob which updates setup-2.{ini, bz2}
> every hour for now.  I also corrected a dumb mistake I made when
> creating the release-2 area.  The symlinks were all broken on the
> mirrors because they were creatd as absolute paths.  I re-created the
> release-2 area with correct relative symlinks to the release area now.
> 
> I guess we'll wait a day until this all settles on the mirrors and
> then I'll create an announcement for the developers and package
> maintainers.

There's a problem, Brian.

I updated my local mirror for a test run.

When I start setup-1.7, it seems to find the already existing c:/cygwin
installation.  Even though I choose "C:/cygwin-2" as installation path,
the new setup-2.ini content is compared against the already existing
installation.  The result is that setup-1.7 offers to install only
the single changed package:  cygwin itself.

Why is setup using the information from the existing installation
even if I choose to install into another directory?  Is it because
the mount points in the registry are looked at?  That's not correct
anymore, given that the registry mount points are not used for the
new installation anyway.

Is it possible to change setup so that it ignores the registry mount
points?  And it must nort write new ones either, btw...


Thanks,
Corinna

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

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Corinna Vinschen]

On Apr 11 18:47, Brian Dessent wrote:
> Corinna Vinschen wrote:
> 
> > Brian, could you please prepare a temporary setup-1.7.exe which
> > only downloads from the release-2 area?
> 
> Okay, I uploaded <http://cygwin.com/setup-1.7.exe> which fetches
> setup-2.{ini,bz2}.  It identifies itself as version 2.590-1.7special on
> the splash page so that we can tell it apart from the normal.

Cool, thanks!  I've set up a cronjob which updates setup-2.{ini, bz2}
every hour for now.  I also corrected a dumb mistake I made when
creating the release-2 area.  The symlinks were all broken on the
mirrors because they were creatd as absolute paths.  I re-created the
release-2 area with correct relative symlinks to the release area now.

I guess we'll wait a day until this all settles on the mirrors and
then I'll create an announcement for the developers and package
maintainers.


Thanks,
Corinna

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

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Brian Dessent]

Corinna Vinschen wrote:

> Brian, could you please prepare a temporary setup-1.7.exe which
> only downloads from the release-2 area?

Okay, I uploaded <http://cygwin.com/setup-1.7.exe> which fetches
setup-2.{ini,bz2}.  It identifies itself as version 2.590-1.7special on
the splash page so that we can tell it apart from the normal.

Brian

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Corinna Vinschen]

On Apr 11 12:27, Andrew Schulman wrote:
> Forgive me, but I stopped following this thread a while back.  I trust you all
> to work out the best method.
> 
> When all of the issues are sorted out, can you please post a summary for package
> maintainers of what we need to do?

Of course.  I will send more details than you'll ever dreamed of
in your worst nightmares.  Dread the might of Cygwin, mortal!
<evil laughter>

Cough...  sorry, I got carried away...


Corinna

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

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Andrew Schulman]

Forgive me, but I stopped following this thread a while back.  I trust you all
to work out the best method.

When all of the issues are sorted out, can you please post a summary for package
maintainers of what we need to do?

Thanks,
Andrew.

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Corinna Vinschen]

On Apr  9 18:28, Corinna Vinschen wrote:
> On Apr  9 10:31, Christopher Faylor wrote:
> > On Wed, Apr 09, 2008 at 06:09:46AM -0700, Brian Dessent wrote:
> > >Corinna Vinschen wrote:
> > >>My favorite would be release-2.  It has nothing to do with the DLL
> > >
> > >Sounds fine to me as well.
> > 
> > It's ok.
> 
> Oh, btw., can we really just use symlinks to the top-level dirs?
> It just occured to me that some package directories contain
> subdirectories for packages which are maintained by another
> maintainer.  For instance the perl and python subdirs...

I've now created a release-2 area.  I used a somewhat intermediary
approach.  The dirs are real dirs, the tar.bz2 files are symlinks
to the release area, the setup.hint and md5.sum files are copies.
The cygwin subdir only contains 1.7.0-1 packages.

Chris, could you please set up another upset which creates the
corresponding setup-2.{bz2,ini} files?

Brian, could you please prepare a temporary setup-1.7.exe which
only downloads from the release-2 area?


Thanks,
Corinna

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

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Corinna Vinschen]

On Apr  9 10:31, Christopher Faylor wrote:
> On Wed, Apr 09, 2008 at 06:09:46AM -0700, Brian Dessent wrote:
> >Corinna Vinschen wrote:
> >>My favorite would be release-2.  It has nothing to do with the DLL
> >
> >Sounds fine to me as well.
> 
> It's ok.

Oh, btw., can we really just use symlinks to the top-level dirs?
It just occured to me that some package directories contain
subdirectories for packages which are maintained by another
maintainer.  For instance the perl and python subdirs...


Corinna

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

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Christopher Faylor]

On Wed, Apr 09, 2008 at 06:09:46AM -0700, Brian Dessent wrote:
>Corinna Vinschen wrote:
>>My favorite would be release-2.  It has nothing to do with the DLL
>
>Sounds fine to me as well.

It's ok.

cgf

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Brian Dessent]

Corinna Vinschen wrote:

> My favorite would be release-2.  It has nothing to do with the DLL

Sounds fine to me as well.

Brian

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Corinna Vinschen]

On Apr  9 05:09, Brian Dessent wrote:
> Corinna Vinschen wrote:
> 
> > Yes.  I'm just wondering if we could do without the final rename of the
> > directories.  The Cygwin release area isn't that small, > 4 Gigs.  A
> > simple top-level directory rename will force all mirrors world-wide to
> > copy the whole area.  Twice, because we will have two release areas.
> > 
> > If that's a minor concern, we do as above.  Otherwise, I'd suggest to
> > create a "release-2" area and to update just setup.exe accordingly.
> 
> We can still rename the .ini files without renaming the directory trees,
> it's all just a matter of how the upset cron job runs.  I'm not sure if
> that really buys any clarity, but what it does do is allow us to "swap
> in" the entire staging area atomically once 1.7 is released.  Otherwise,
> only users who updated their setup.exe would ever see the 1.7 release. 
> I can almost see the email messages now: "Is Cygwin dead?  I haven't
> seen a new release of the DLL or any updated packages in the last <nn>
> months?!?!"

Ok, let's decide about renaming directories at some later point.  For now,
I will just create a second dir for the 1.7 test release.  Last call for
the right name:

  release-ng
  release-2
  release-2008
  release-1.7

My favorite would be release-2.  It has nothing to do with the DLL
version number, it's just release 2 of the net distro.  I will happily
use any other name as long as we can agree to take off in the next days.


Corinna

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

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Brian Dessent]

Corinna Vinschen wrote:

> Yes.  I'm just wondering if we could do without the final rename of the
> directories.  The Cygwin release area isn't that small, > 4 Gigs.  A
> simple top-level directory rename will force all mirrors world-wide to
> copy the whole area.  Twice, because we will have two release areas.
> 
> If that's a minor concern, we do as above.  Otherwise, I'd suggest to
> create a "release-2" area and to update just setup.exe accordingly.

We can still rename the .ini files without renaming the directory trees,
it's all just a matter of how the upset cron job runs.  I'm not sure if
that really buys any clarity, but what it does do is allow us to "swap
in" the entire staging area atomically once 1.7 is released.  Otherwise,
only users who updated their setup.exe would ever see the 1.7 release. 
I can almost see the email messages now: "Is Cygwin dead?  I haven't
seen a new release of the DLL or any updated packages in the last <nn>
months?!?!"

Brian

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Corinna Vinschen]

On Apr  8 16:27, Brian Dessent wrote:
> Corinna Vinschen wrote:
> 
> > Sorry, but I didn't remember that.  Why didn't you just tell us?
> 
> I thought we were talking about two different things.
> 
> As I see it, here are the *conceptual* things we're dealing with:
> 
> A) We want to have a tree of packages that is still usable for users of
> 9x/ME after 1.7 is released, even if it's not updated often or at all. 
> Since setup can determine this at runtime, it can simply decide to fetch
> a different .ini.
> 
> B) We want to have a playground where maintainers and advanced users can
> try out 1.7 and packages built against 1.7, in preparation for the
> release.
> 
> C) During that prep period (i.e. right now) we want the "standard" 1.5
> tree to remain and be the default for users.
> 
> Now, having written that it appears that (A) and (C) are really the same
> thing.  So maybe we only actually have two things: the current tree
> which will get renamed to _legacy after 1.7 is released, and a new
> playground which will be promoted to the standard "release" tree when
> 1.7 is ready and tested.

That matches it.

> So it appears this is what we want:
> 
> For right now/temporary:
> 
>  - "standard" setup.exe grabs setup.ini/bz2 for both 9x/ME and NT (i.e.
> no version checking code)
>  - "advanced user/maintainer" setup.exe grabs setup-1.7.ini/bz2
> unconditionally which will be a new tree we create, which contains
> packages built against 1.7
> 
> At point of 1.7 release:
> 
>  - rename setup.ini to setup_legazy.ini
>  - rename setup-1.7.init to setup.ini
>  - release new setup.exe that replaces both of the above, with 9x/ME
> check enabled (back to one version of setup.exe)
> 
> Sound about right?

Yes.  I'm just wondering if we could do without the final rename of the
directories.  The Cygwin release area isn't that small, > 4 Gigs.  A
simple top-level directory rename will force all mirrors world-wide to
copy the whole area.  Twice, because we will have two release areas.

If that's a minor concern, we do as above.  Otherwise, I'd suggest to
create a "release-2" area and to update just setup.exe accordingly.

> And yes, it's rather trivial to release a new setup.exe with the ini
> name tweaked, so once we decide on that I can upload such to the
> website.

Thanks,
Corinna

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

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Brian Dessent]

Corinna Vinschen wrote:

> Sorry, but I didn't remember that.  Why didn't you just tell us?

I thought we were talking about two different things.

As I see it, here are the *conceptual* things we're dealing with:

A) We want to have a tree of packages that is still usable for users of
9x/ME after 1.7 is released, even if it's not updated often or at all. 
Since setup can determine this at runtime, it can simply decide to fetch
a different .ini.

B) We want to have a playground where maintainers and advanced users can
try out 1.7 and packages built against 1.7, in preparation for the
release.

C) During that prep period (i.e. right now) we want the "standard" 1.5
tree to remain and be the default for users.

Now, having written that it appears that (A) and (C) are really the same
thing.  So maybe we only actually have two things: the current tree
which will get renamed to _legacy after 1.7 is released, and a new
playground which will be promoted to the standard "release" tree when
1.7 is ready and tested.

> How do you differ the setup.ini files if you only have different release
> subdirs?  setup_legacy.ini?

Sorry, I actually misremembered how this was implemented.  The switching
happens at the .ini level:

#define SETUP_INI_FILENAME (IsWindowsNT () ? "setup.ini" :
"setup_legacy.ini")
#define SETUP_BZ2_FILENAME (IsWindowsNT () ? "setup.bz2" :
"setup_legacy.bz2")

And of course the .ini file contains the filename of the package
including the "release" part:

version: 1.5.25-11
install: release/cygwin/cygwin-1.5.25-11.tar.bz2 1427217
e1f969931a1e18855716f2c57c3a876a

Thus, setup just looks for a different .ini, the thing on sourceware
that generates that ini can decide what the dirs are named.

> When I came up with that a couple of days ago, I thought it might be bad
> to rename the current release area for 1.5 so that it keeps working as
> is and downloading from the 1.7 release area requires to make the
> conscience choice to use the 1.7 setup.  If we can do this with a
> release-1.7 plus a setup-1.7.ini file, than that's ok for me, too.

So it appears this is what we want:

For right now/temporary:

 - "standard" setup.exe grabs setup.ini/bz2 for both 9x/ME and NT (i.e.
no version checking code)
 - "advanced user/maintainer" setup.exe grabs setup-1.7.ini/bz2
unconditionally which will be a new tree we create, which contains
packages built against 1.7

At point of 1.7 release:

 - rename setup.ini to setup_legazy.ini
 - rename setup-1.7.init to setup.ini
 - release new setup.exe that replaces both of the above, with 9x/ME
check enabled (back to one version of setup.exe)

Sound about right?

And yes, it's rather trivial to release a new setup.exe with the ini
name tweaked, so once we decide on that I can upload such to the
website.

Brian

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Corinna Vinschen]

On Apr  8 23:46, Corinna Vinschen wrote:
> On Apr  8 14:16, Brian Dessent wrote:
> > Okay, so, several years ago setup.exe HEAD was modified to look for
> > "release" and "release_legacy" as the base dirname for packages
> > depending on whether it was running on 9x/ME or NT/2k/etc.  I understand
> 
> Sorry, but I didn't remember that.  Why didn't you just tell us?
> 
> How do you differ the setup.ini files if you only have different release
> subdirs?  setup_legacy.ini?
> 
> > that having Cygwin 1.7 playground is a different concept, but why should
> > it be handled differently?  Why not "release_1.7"?  This is all
> > temporary anyway IIUC, since it's just for testing packages built with
> > 1.7, which will eventually all be moved over into just plain "release"
> > anyway, right?  If this is *not* temporary then how does it fit into the
> > idea of having a legacy 9x/ME area?
> 
> When I came up with that a couple of days ago, I thought it might be bad
> to rename the current release area for 1.5 so that it keeps working as
> is and downloading from the 1.7 release area requires to make the
> conscience choice to use the 1.7 setup.  If we can do this with a
> release-1.7 plus a setup-1.7.ini file, than that's ok for me, too.

And, apart from the actual names used, can we get a matching setup.exe
perhaps this week?  Or the next one?


Corinna

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

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Corinna Vinschen]

On Apr  8 17:39, Christopher Faylor wrote:
> On Tue, Apr 08, 2008 at 11:07:26PM +0200, Corinna Vinschen wrote:
> >With a dash?  cygwin-ng?  Like syslog-ng.  I was going to suggest this
> >too, but I didn't want to copy the naming too bluntly.
> 
> We actually use "ng" internally to Netapp.  I actually wanted to call my
> project either "ds9" or "voyager" but I got vetoed.

I assume Netapp didn't want to risk a law suite with CBS...

> >I guess we should use "cygwin-notasnewbutstillnewenough".  I'm still
> >more leaning towards cygwin-2008.  You shouldn't have suggested the
> >name.  It's all your fault.
> 
> I hate the name!  Hate it!
> 
> But I don't really care.  cygwin-2008 is fine with me.  However, I
> predict that cgf-2012 will probably be grumbling about that name
> eventually.

Looks like Brian made this whole naming discussion obsolete two years
ago...


Corinna

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

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Corinna Vinschen]

On Apr  8 14:16, Brian Dessent wrote:
> Corinna Vinschen wrote:
> 
> > Why, we could always name the next versions "cygwin-newer",
> > "cygwin-evenmorenew", "cygwin-newerthannew" and
> > "cygwin-reallyreallynew-imeanit".
> > 
> > > How about cygwinng?
> > 
> > With a dash?  cygwin-ng?  Like syslog-ng.  I was going to suggest this
> > too, but I didn't want to copy the naming too bluntly.  I guess we
> > should use "cygwin-notasnewbutstillnewenough".  I'm still more leaning
> > towards cygwin-2008.  You shouldn't have suggested the name.  It's all
> > your fault.
> 
> Okay, so, several years ago setup.exe HEAD was modified to look for
> "release" and "release_legacy" as the base dirname for packages
> depending on whether it was running on 9x/ME or NT/2k/etc.  I understand

Sorry, but I didn't remember that.  Why didn't you just tell us?

How do you differ the setup.ini files if you only have different release
subdirs?  setup_legacy.ini?

> that having Cygwin 1.7 playground is a different concept, but why should
> it be handled differently?  Why not "release_1.7"?  This is all
> temporary anyway IIUC, since it's just for testing packages built with
> 1.7, which will eventually all be moved over into just plain "release"
> anyway, right?  If this is *not* temporary then how does it fit into the
> idea of having a legacy 9x/ME area?

When I came up with that a couple of days ago, I thought it might be bad
to rename the current release area for 1.5 so that it keeps working as
is and downloading from the 1.7 release area requires to make the
conscience choice to use the 1.7 setup.  If we can do this with a
release-1.7 plus a setup-1.7.ini file, than that's ok for me, too.


Corinna

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

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Christopher Faylor]

On Tue, Apr 08, 2008 at 11:07:26PM +0200, Corinna Vinschen wrote:
>On Apr  8 14:41, Christopher Faylor wrote:
>> On Tue, Apr 08, 2008 at 07:40:13PM +0200, Corinna Vinschen wrote:
>> >On Apr  8 13:26, Christopher Faylor wrote:
>> >> cygwin-xp?  cygwin-2008?
>> >
>> >cysta? :)
>> >
>> >cygwin-2008 isn't bad, though.
>> >
>> >> cygwin-nextgen?
>> >
>> >Or just cygwin-new, maybe.  I'd take any of them, -new or -2008.
>> 
>> In my experience, adding a "new" to any directory or file is a
>> guaranteed way of ensuring that the name will not always be accurate.
>
>Why, we could always name the next versions "cygwin-newer",
>"cygwin-evenmorenew", "cygwin-newerthannew" and
>"cygwin-reallyreallynew-imeanit".
>
>> How about cygwinng?
>
>With a dash?  cygwin-ng?  Like syslog-ng.  I was going to suggest this
>too, but I didn't want to copy the naming too bluntly.

We actually use "ng" internally to Netapp.  I actually wanted to call my
project either "ds9" or "voyager" but I got vetoed.

>I guess we should use "cygwin-notasnewbutstillnewenough".  I'm still
>more leaning towards cygwin-2008.  You shouldn't have suggested the
>name.  It's all your fault.

I hate the name!  Hate it!

But I don't really care.  cygwin-2008 is fine with me.  However, I
predict that cgf-2012 will probably be grumbling about that name
eventually.

cgf

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Brian Dessent]

Corinna Vinschen wrote:

> Why, we could always name the next versions "cygwin-newer",
> "cygwin-evenmorenew", "cygwin-newerthannew" and
> "cygwin-reallyreallynew-imeanit".
> 
> > How about cygwinng?
> 
> With a dash?  cygwin-ng?  Like syslog-ng.  I was going to suggest this
> too, but I didn't want to copy the naming too bluntly.  I guess we
> should use "cygwin-notasnewbutstillnewenough".  I'm still more leaning
> towards cygwin-2008.  You shouldn't have suggested the name.  It's all
> your fault.

Okay, so, several years ago setup.exe HEAD was modified to look for
"release" and "release_legacy" as the base dirname for packages
depending on whether it was running on 9x/ME or NT/2k/etc.  I understand
that having Cygwin 1.7 playground is a different concept, but why should
it be handled differently?  Why not "release_1.7"?  This is all
temporary anyway IIUC, since it's just for testing packages built with
1.7, which will eventually all be moved over into just plain "release"
anyway, right?  If this is *not* temporary then how does it fit into the
idea of having a legacy 9x/ME area?

Brian

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Corinna Vinschen]

On Apr  8 14:43, Christopher Faylor wrote:
> On Tue, Apr 08, 2008 at 02:34:03PM -0400, Charles Wilson wrote:
> >If we do choose to name the release directory "cygwin-2008", we probably
> >ought to try to get cygwin-1.7 out the door before, say, Christmas, tho.
> ><g>
> 
> Uh oh.  I'm hyperventilating now.
> 
> Actually, given what is going into cygwin-1.7, the directory probably
> should be called "cygwin-corinna".

Naah!


Corinna

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

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Corinna Vinschen]

On Apr  8 14:41, Christopher Faylor wrote:
> On Tue, Apr 08, 2008 at 07:40:13PM +0200, Corinna Vinschen wrote:
> >On Apr  8 13:26, Christopher Faylor wrote:
> >> cygwin-xp?  cygwin-2008?
> >
> >cysta? :)
> >
> >cygwin-2008 isn't bad, though.
> >
> >> cygwin-nextgen?
> >
> >Or just cygwin-new, maybe.  I'd take any of them, -new or -2008.
> 
> In my experience, adding a "new" to any directory or file is a
> guaranteed way of ensuring that the name will not always be accurate.

Why, we could always name the next versions "cygwin-newer",
"cygwin-evenmorenew", "cygwin-newerthannew" and
"cygwin-reallyreallynew-imeanit".

> How about cygwinng?

With a dash?  cygwin-ng?  Like syslog-ng.  I was going to suggest this
too, but I didn't want to copy the naming too bluntly.  I guess we
should use "cygwin-notasnewbutstillnewenough".  I'm still more leaning
towards cygwin-2008.  You shouldn't have suggested the name.  It's all
your fault.


Corinna

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

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Christopher Faylor]

On Tue, Apr 08, 2008 at 02:34:03PM -0400, Charles Wilson wrote:
>If we do choose to name the release directory "cygwin-2008", we probably
>ought to try to get cygwin-1.7 out the door before, say, Christmas, tho.
><g>

Uh oh.  I'm hyperventilating now.

Actually, given what is going into cygwin-1.7, the directory probably
should be called "cygwin-corinna".

cgf

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Christopher Faylor]

On Tue, Apr 08, 2008 at 07:40:13PM +0200, Corinna Vinschen wrote:
>On Apr  8 13:26, Christopher Faylor wrote:
>> On Tue, Apr 08, 2008 at 06:26:46PM +0200, Corinna Vinschen wrote:
>> >On Apr  4 14:15, Corinna Vinschen wrote:
>> >> On Apr  3 20:49, Christopher Faylor wrote:
>> >> > [responding to the thread which started it all]
>> >> > On Wed, Apr 02, 2008 at 02:35:51PM +0200, Corinna Vinschen wrote:
>> >> > >- We create a ftp://cygwin.com/pub/cygwin-1.7 dir.
>> >> > >
>> >> > >- Under that dir, we create the full release directory structure as it
>> >> > >  exists in the parallel cygwin dir, except for the "cygwin" itself.
>> >> > 
>> >> > So far so good.
>> >
>> >I'm just not sure we should really call it "cygwin-1.7".  What would
>> >be a good name, which does not refer to the actual version number?
>> >
>> >  "Cygwin" with uppercase C?
>> >
>> >I'm volunteering to create the directory layout...
>> 
>> Too bad we can't call it cygwin2.dll.
>> 
>> I don't think making it differ by case is a good idea.  This is bound
>> to cause problems for Windows somehow.
>> 
>> cygwin-xp?  cygwin-2008?
>
>cysta? :)
>
>cygwin-2008 isn't bad, though.
>
>> cygwin-nextgen?
>
>Or just cygwin-new, maybe.  I'd take any of them, -new or -2008.

In my experience, adding a "new" to any directory or file is a
guaranteed way of ensuring that the name will not always be accurate.

How about cygwinng?

cgf

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Charles Wilson]

On Tue, Apr 08, 2008 at 13:26:46 -0400, Christopher Faylor wrote:
>On Tue, Apr 08, 2008 at 06:26:46PM +0200, Corinna Vinschen wrote:
>>I'm just not sure we should really call it "cygwin-1.7".  What would
>>be a good name, which does not refer to the actual version number?
>>
>>  "Cygwin" with uppercase C?
>
>I don't think making it differ by case is a good idea.  This is bound
>to cause problems for Windows somehow.

I agree.

>cygwin-xp?  cygwin-2008?
>
>cygwin-nextgen?

I'd lean towards cygwin-2008. As we have learned with the various
Microsoft products, the "year" in a product or distribution name is only
tangentially related to the product's lifespan, birthdate, or
end-of-life. Plus using cygwin-2008 doesn't restrict us from continuing
to use it with cygwin-1.9, cygwin-1.11, etc in the future -- unless we
have a paradigm-breaking new release (again), like cygwin-1.7 is.

I doubt such a thing would occur twice in one year.

If we do choose to name the release directory "cygwin-2008", we probably
ought to try to get cygwin-1.7 out the door before, say, Christmas, tho.
<g>

--
Chuck

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Corinna Vinschen]

On Apr  8 13:26, Christopher Faylor wrote:
> On Tue, Apr 08, 2008 at 06:26:46PM +0200, Corinna Vinschen wrote:
> >On Apr  4 14:15, Corinna Vinschen wrote:
> >> On Apr  3 20:49, Christopher Faylor wrote:
> >> > [responding to the thread which started it all]
> >> > On Wed, Apr 02, 2008 at 02:35:51PM +0200, Corinna Vinschen wrote:
> >> > >- We create a ftp://cygwin.com/pub/cygwin-1.7 dir.
> >> > >
> >> > >- Under that dir, we create the full release directory structure as it
> >> > >  exists in the parallel cygwin dir, except for the "cygwin" itself.
> >> > 
> >> > So far so good.
> >
> >I'm just not sure we should really call it "cygwin-1.7".  What would
> >be a good name, which does not refer to the actual version number?
> >
> >  "Cygwin" with uppercase C?
> >
> >I'm volunteering to create the directory layout...
> 
> Too bad we can't call it cygwin2.dll.
> 
> I don't think making it differ by case is a good idea.  This is bound
> to cause problems for Windows somehow.
> 
> cygwin-xp?  cygwin-2008?

cysta? :)

cygwin-2008 isn't bad, though.

> cygwin-nextgen?

Or just cygwin-new, maybe.  I'd take any of them, -new or -2008.


Corinna

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

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Christopher Faylor]

On Tue, Apr 08, 2008 at 06:26:46PM +0200, Corinna Vinschen wrote:
>On Apr  4 14:15, Corinna Vinschen wrote:
>> On Apr  3 20:49, Christopher Faylor wrote:
>> > [responding to the thread which started it all]
>> > On Wed, Apr 02, 2008 at 02:35:51PM +0200, Corinna Vinschen wrote:
>> > >- We create a ftp://cygwin.com/pub/cygwin-1.7 dir.
>> > >
>> > >- Under that dir, we create the full release directory structure as it
>> > >  exists in the parallel cygwin dir, except for the "cygwin" itself.
>> > 
>> > So far so good.
>
>I'm just not sure we should really call it "cygwin-1.7".  What would
>be a good name, which does not refer to the actual version number?
>
>  "Cygwin" with uppercase C?
>
>I'm volunteering to create the directory layout...

Too bad we can't call it cygwin2.dll.

I don't think making it differ by case is a good idea.  This is bound
to cause problems for Windows somehow.

cygwin-xp?  cygwin-2008?

cygwin-nextgen?

cgf

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Corinna Vinschen]

On Apr  4 14:15, Corinna Vinschen wrote:
> On Apr  3 20:49, Christopher Faylor wrote:
> > [responding to the thread which started it all]
> > On Wed, Apr 02, 2008 at 02:35:51PM +0200, Corinna Vinschen wrote:
> > >- We create a ftp://cygwin.com/pub/cygwin-1.7 dir.
> > >
> > >- Under that dir, we create the full release directory structure as it
> > >  exists in the parallel cygwin dir, except for the "cygwin" itself.
> > 
> > So far so good.

I'm just not sure we should really call it "cygwin-1.7".  What would
be a good name, which does not refer to the actual version number?

  "Cygwin" with uppercase C?

I'm volunteering to create the directory layout...

> > >- All files in the original release dir are hardlinked into their
> > >  matching spot in the cygwin-1.7 dir.
> > 
> > I don't like hardlinking.  It's too easy to have unintended side
> > effects.  I think I'd rather just symlink the directories in the new
> > release area then rm the symlink and create a new directory when it's
> > time to populate the directory with a 1.7 version.
> 
> In theory I agree, but it lets more room for mistakes.  It's very easy
> to have a new package and just move the files to the directory, instead
> of checking if the directory is a symlink or a real dir.  If the dir
> is a real dir from the start, you just dump the new package into the
> dir and remove the oldest files and be done.
> 
> Anyway, it's nothing I really get excited about.

...using the directory symlink approach.

Could one of the setup.exe guys then create a matching setup.exe
binary?  Please?


Thanks,
Corinna

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

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Christopher Faylor]

On Mon, Apr 07, 2008 at 12:34:50AM +1000, klavins@netspace.net.au wrote:
>As far as I understand it, the current Cygwin runtime architecture uses shared 
>memory for those Cygwin processes attached to the Cygwin DLL, and a static 
>registry location for its static mount table.  As already discussed, the static 
>mount table could move out into the Cygwin file system, freeing up any registry 
>conflict for multiple Cygwins.
>
>Is it feasible to consider that more than one Cygwin shared memory be created, 
>one for each of multiple Cygwins?  Each Cygwin could be uniquely identified by 
>the UNC path to its Cygwin DLL.  The static registry location, or indeed 
>another singleton shared memory, could then be used for mapping from Cygwin DLL 
>UNC path to the UNC path to its shared memory.

Is it feasible?  It's just a simple matter of programming but it is not
as simple as what you are saying above.

is it planned?  AFAIK, no.

Is this the right mailing list to discuss changes to the architecture of the cygwin
DLL?  No.

cgf

RE: [HEADSUP] Let's start a Cygwin 1.7 release area

[klavins]

> On Thu, 3 Apr 2008, Corinna Vinschen wrote:
> [snip]
> I don't understand this.  As discussed somewhat later, if the root dir 
> follows automatically from where the DLL itself resides.  Which, btw., 
> the current code doesn't do right.  I called GetModuleFileName(NULL) 
> which returns the path of the current application, not the path of the 
> Cygwin DLL.  I'll fix that.
> 
> [snip]
> Which is too late for cygrunsrv itself, right?  The idea is to avoid 
> having to add the Cygwin bin dir to the system variable %PATH%.  If 
> you want to accomplish that, cygrunsrv itself must be independent of it.
> That's only the case if it shares the bin dir with the Cygwin DLL.
> 
> > > Right now I must admit that I prectically don't care if my 
> > > packages install the binaries in /bin or /usr/bin.
> >
> > /bin should contain programs that should work even if the PATH and
> mounts
> > are screwed up.  So, "kill", "shutdown", etc.
> 
> And cygrunsrv.

From earlier discussions it seems that there are some "nice to have" features 
in future Cygwin for all sorts of real-life not-only-developer-user reasons:
  - users plugging in possibly more than one USB key each containing possibly 
different Cygwins
  - read-only Samba or Windows shares containing a common Cygwin installation 
for multiple client computers
  - 64-bit Windows installations having both 32-bit and 64-bit Cygwin 
installations

As far as I understand it, the current Cygwin runtime architecture uses shared 
memory for those Cygwin processes attached to the Cygwin DLL, and a static 
registry location for its static mount table.  As already discussed, the static 
mount table could move out into the Cygwin file system, freeing up any registry 
conflict for multiple Cygwins.

Is it feasible to consider that more than one Cygwin shared memory be created, 
one for each of multiple Cygwins?  Each Cygwin could be uniquely identified by 
the UNC path to its Cygwin DLL.  The static registry location, or indeed 
another singleton shared memory, could then be used for mapping from Cygwin DLL 
UNC path to the UNC path to its shared memory.

Given that structure, any process using a Cygwin DLL could at Cygwin DLL attach 
time look in the static registry location or the singleton shared memory to 
locate its shared memory UNC path, then go on from there to locate its dynamic 
mount table, security environment, etc., etc.

What do you think?
------------------------------------------------------------------------
 Peter Klavins                                  klavins@netspace.net.au


------------------------------------------------------------
This email was sent from Netspace Webmail: http://www.netspace.net.au

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Corinna Vinschen]

On Apr  4 14:22, Corinna Vinschen wrote:
> On Apr  3 17:46, Charles Wilson wrote:
> > Christopher Faylor wrote:
> >> Why do we need a fstab.$SID and linux doesn't need this?
> >
> > Well, I like to create user mounts for each user (Guest, Administrator, me) 
> > like this:
> >
> > mount -f -u -b "C:/Documents and Settings/<user>/My Documents" "/mydocs"
> > mount -f -u -b "C:/Documents and Settings/<user>/Desktop" "/desktop"
> > [...]
> 
> I understand that.  Well, we shouldn't make this overly public, but
> keeping the fstab.$SID handling in doesn't hurt the least bit.
> [...]

I just applied a patch which changes the fstab handling somewhat.  I
made especially a change to how system and user mount points are
handled, which is supposed to support sysadmins in commercial or
organizational environments.

- The paths in the first and second field may contain nuts^Wspaces.
  You specify them the same way as in a Linux fstab, using the special
  string "\040":

    C:/Documents\040and\040Settings /my\040docs ntfs binary 0 0

- mount(1) and umount(1) don't write back any information to the
  registry.  Cygwin still reads mount points from the registry, though,
  if no fstab file exists.  This is just left in for the transformation
  process.  It will get removed at one point.

- All mount points in /etc/fstab are system mount points by default,
  all other mount points are always user mount points.  The important
  thing here is, that user mount points can't override system mount
  points anymore.  If you try that, you get an EPERM error.  The reason
  for this change is to allow sysadmins to specify paths in /etc/fstab
  which no user is allowed to screw up.  Paths which the user may
  umount or re-mount can be marked as user mounts by the admin.

- The flags string in the fstab file also understands the flags "system"
  and "user" now, to allow the sysadmin to specify default paths which a
  user may change.

- Cygwin creates "/cygdrive" as default cygdrive prefix now before
  reading the fstab files.  It's a user mount by default, so the user
  can override it.  If the sysadmin decides to add the cygdrive prefix
  to /etc/fstab as system mount, no user can override it, but gets an
  EPERM instead.

- The user-specific fstab file is now /etc/fstab.$USER, not /etc/fstab.$SID
  anymore.  My significant other convinced me that nobody(TM) knows what
  a SID is.  I pointed out the Cygwin user's guide, but...

- I hacked a new Cygwin postinstall script, which is called "postinstall"
  in the Cygwin sources, and which gets copied to
  /etc/postinstall/000-cygwin-post-install.sh at installation time.
  It creates a default /etc/fstab file which (for now) contains the
  standard mount points for /usr/bin and /usr/lib.  The script also
  creates the /dev/shm and /dev/mqueue subdirectories which are required
  for POSIX semaphores/shared memory/message queues, but that's another
  story.

  The /etc/fstab file which gets created by this script contains
  lots of comment, which is basically taken from Linux' fstab man page.
  I added Cygwin specifc descriptions and examples.  I hope it helps.
  I would be glad if people could read the text and comment on it.


Corinna

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

RE: [HEADSUP] Let's start a Cygwin 1.7 release area

[Karl M]

Hi All...

I like this!!!

> Date: Thu, 3 Apr 2008 11:42:20 +0200
> From: corinna
> Subject: Re: [HEADSUP] Let's start a Cygwin 1.7 release area
>
> For a start, please note that this patch is just preliminary.
>
> The actual problem is still one of the problems I noted in my mail
> http://cygwin.com/ml/cygwin-developers/2008-03/msg00000.html, to which I
> didn't get a reply, except from Brian.
>
> - The POSIX path of mount points is restricted to 256 characters.
> That's because it's used as the value name of a registry value and
> value names are restricted to (surprise!) 256 chars. A decision
> and, perhaps, coding has to be done:
>
> - Do we stick to this restriction?
> - Do we introduce a new mount point storage in the registry?
> - Do we drop registry mount points and store mount points in future
> in fstab-like files as, say, /etc/fstab (system mount points) and
> ~/.fstab (user mount points)?
>
> Having said that...
>
> On Apr 2 17:56, Charles Wilson wrote:
>> Corinna Vinschen wrote:
>>> I have applied a preliminary patch to Cygwin which allows to load the
>>> mount entries from /etc/fstab and /etc/fstab.. If none of
>>> these files is available, the DLL falls back to reading the mount points
>>> from the registry.
>>
>> I like this. A lot.
>
> AOL ;)
>
>>> Cygwin finds the fstab files by fetching it's own Win32 path and then
>>> replacing the last two path components with etc/fstab or
>>> etc/fstab., like this:
>>> Get own path ==> C:\\cygwin\\bin\\cygwin1.dll
>>> Where's fstab? ==> C:\\cygwin\\etc\\fstab
>>
>> So, it implicitly computes where / is?
>
> No, it doesn't. It just snips away the last two path components and
> tacks the etc/fstab string on. Plus the .$SID to get the user mounts.
>
> After the mount points have been read, root can potentially be
> somewhere else entirely.
>
>>> The layout of the fstab file follows the Linux layout. As example,
>>> these are my fstab files:
>>> $ cat /etc/fstab
>>> C:\cygwin / ntfs binary 0 0
>>
>> Which means that the line above really ought to match the computed '/', or
>> bad things might happen, right? If so, then it is redundant to specify it
>> here. Perhaps this should just be autocomputed...since the fstype and last
>> two elements are ignored.
>
> Yes, I thought about this, too. It doesn't really seem to make much
> sense to redefine /. As for /usr/bin and /usr/lib, these paths are
> not inherently defined by the DLL. They exist because a decision
> has been made how to create a Cygwin installation in the net distro.
> This could be changed in future, or our internal Red Hat release
> could need another layout. There's no reason to couple this distro
> decision to the DLL, IMHO.
>
>> [...]
>> Maybe there should be "special" rules for the three special autocomputed
>> mount points:
>>
>> # NOTE: the three "magic" auto-computed paths are present
>> # in this file strictly so that mount options may be specified.
>> C:\This\Path\Is\AutoComputed / ntfs binary 0 0
>> C:\This\Path\Is\AutoComputed /usr/bin ntfs binary 0 0
>> C:\This\Path\Is\AutoComputed /usr/lib ntfs binary 0 0
>
> Or simply
>
> root / ntfs binary 0 0
>
> and stick to /usr/bin and /usr/lib as they are today.
>
>> Oh, and I'm guessing that setup-1.7 should create /etc/fstab if "install
>> for all users", and "/etc/fstab.SID" if "just me"? Otherwise, you'll
>> clobber the "old" cygwin's registry entries every time you try to update
>> your "new" cygwin installation...
>
> That's right. I think this could be done by a simple postinstall script
> which gets called from setup-1.7. Consider a package which comes with
> a default /etc/fstab which consists only of the above entry for the root
> dir. The script would simply add the /usr/bin and /usr/lib entries.
> I have the vague feeling it would be sufficient to install only a
> /etc/fstab, even in "just me" mode, though. The fstab.$SID file is
> only necessary in multi-user installations, IMHO.
For multiple "Just Me" installations?
>
> Another problem is that the 1.7 mount(1) still creates the mount entries
> in the registry. This should be removed, if we stick to the file based
> approach. mount would only create temporary mount points which are
> only valid in this single session, until the last Cygwin process in this
> session exits. A bit like a reboot on Linux :)
>
>> One little wrinkle that makes switching between two cygwin installations
>> difficult: services. Do you
>>
>> (1) stop/uninstall -- switch-to-other-cygwin -- reinstall/start as part of
>> each switch, or
>>
>> (2) somehow change each service's target path (and PATH environment
>> variable, if the service.exe is not in /bin. For the proposed 1.7.0 you
>> have to ensure that the "correct" cygwin1.dll is used), and then restart?
>>
>> (3) install services under different names for the two installations, and
>> just remember to stop all the old ones, before trying to use any tools from
>> the "new" installation, and restart the "new" services under their
>> alternate installation names? The installation part of this proposal could
>> be automated in the foo-config scripts:
>> if cygwin_17
>> then service_name=sshd_17
>> else service_name=sshd
>> fi
>> etc.
>
> Consider that a parallel installation is not really for the normal user.
> My answer to this question is, whatever is most convenient for you.
> Personally I tend to option 3, without the changes in the foo-config
> scripts. I'd do the second service installation manually. It's not
> that hard.
>
I think that I prefer (1). I have cygwin-shutdown and cygwin-startup scripts
anyway, because it makes stopping and starting to run setup easier...so this
is no different. I actually uninstall and reinstall the services in my cygwin-startup
script so that the path gets updated if I install/uninstall any other software. I
have one fewer thing to remember that way.
>
...Karl
_________________________________________________________________
Get in touch in an instant. Get Windows Live Messenger now.
http://www.windowslive.com/messenger/overview.html?ocid=TXT_TAGLM_WL_Refresh_getintouch_042008

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Corinna Vinschen]

On Apr  3 17:46, Charles Wilson wrote:
> Christopher Faylor wrote:
>
>> Why do we need a fstab.$SID and linux doesn't need this?
>
> Well, I like to create user mounts for each user (Guest, Administrator, me) 
> like this:
>
> mount -f -u -b "C:/Documents and Settings/<user>/My Documents" "/mydocs"
> mount -f -u -b "C:/Documents and Settings/<user>/Desktop" "/desktop"
>
> mainly for convenience, but also because spaces and the command line don't 
> mix well. Linux doesn't have to deal with asinine decisions made in 
> Redmond, WA...from a hidden microphone in 1995: "LOOK! We can support 
> spaces in filenames as well as filenames longer than 8.3, so let's use them 
> EVERYWHERE! Spaces for EVERYBODY! Really long and hard to type system 
> paths, like 'Documents and Settings'! Whoo-pee!! Steve Jobs has got nuthin' 
> on us!"
>
>
> I realize that on (clean-install, non-upgrade) Vista, this is less of an 
> issue, because the "new" paths are
>
> mount -f -u -b "C:/Users/<user>/Documents" "/mydocs"
> mount -f -u -b "C:/Users/<user>/Desktop" "/desktop"
>
> but XP and 2k aren't going anywhere for a long long time, if even one of 
> the horror stories I've read about Vista are true...

I understand that.  Well, we shouldn't make this overly public, but
keeping the fstab.$SID handling in doesn't hurt the least bit.

Btw., since setup.exe (or the subsequent script) can and will always create
an /etc/fstab file, doesn't that mean we can get rid of the choices
"all users" and "just me"?  The only difference between these two choices
is in which registry area the mount points go.  So there's no reason to
stick to that choice.

And while we're at it, I don't see any need to stick to the UNIX/DOS
choice either.  We should always install binary mount points.  If the
user needs text mounts, there's an editor and a fstab file, right?


Corinna

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

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Corinna Vinschen]

On Apr  3 20:49, Christopher Faylor wrote:
> [responding to the thread which started it all]
> On Wed, Apr 02, 2008 at 02:35:51PM +0200, Corinna Vinschen wrote:
> >- We create a ftp://cygwin.com/pub/cygwin-1.7 dir.
> >
> >- Under that dir, we create the full release directory structure as it
> >  exists in the parallel cygwin dir, except for the "cygwin" itself.
> 
> So far so good.
> 
> >- All files in the original release dir are hardlinked into their
> >  matching spot in the cygwin-1.7 dir.
> 
> I don't like hardlinking.  It's too easy to have unintended side
> effects.  I think I'd rather just symlink the directories in the new
> release area then rm the symlink and create a new directory when it's
> time to populate the directory with a 1.7 version.

In theory I agree, but it lets more room for mistakes.  It's very easy
to have a new package and just move the files to the directory, instead
of checking if the directory is a symlink or a real dir.  If the dir
is a real dir from the start, you just dump the new package into the
dir and remove the oldest files and be done.

Anyway, it's nothing I really get excited about.

> >- The "cygwin" subdir gets created and filled with only the first Cygwin
> >  DLL 1.7.0 tar files.
> >
> >- Chris starts a second upset which creates the setup.ini file in
> >  the cygwin-1.7 dir.
> 
> I can do this but on top of this, I'd actually like to implement my plan
> for allowing people to control their own directories.  I hadn't thought
> about adding a 1.7 directory but it should still be doable.
> 
> If we don't do this, I think we'll be awash in a sea of RFU's and me
> pulling what little hair I have left out over upset errors.
> 
> I'd also like to finally have a package lint program which could be
> invoked automatically.  Anyone want to write one of those?
> 
> I don't want to necessarily gate 1.7 on these things but a package lint
> is really long overdue, IMO.  You could even write one that took a
> setup.ini as input to make sure that the setup.hint was correct to help
> stem the tide of upset errors.

That's a good idea.  Unfortunately I don't have the time right now...


Corinna

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

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Charles Wilson]

Christopher Faylor wrote:
> On Thu, Apr 03, 2008 at 06:01:37PM -0500, Charles Wilson wrote:
>> Yep. A few things off the top of my head:
>>
>> 1) the shells need to install both in /bin and /usr/bin. This is up to the 
>> individual maintainers when they build their -1.7 versions, but to take on 
>> super-duper important shell:
>> Or "tough. you want to run /bin/bash, ensure /usr/bin is in your PATH"
                               ^^^^              ^^^^^^^^
> 
> Yes. 

Geez. This was the really-just-a-joke-WJM response. Doing this will 
cause no END of trouble and lots of FAQs. It means I can't have a 
shortcut whose target is
   "C:/cygwin17/bin/bash -e somescript"
or even
   "cmd /k C:/cygwin17/bin/bash.exe -e somescript"
unless my environment settings (either system or personal) force 
/usr/bin into my PATH (otherwise /bin/bash can't find cygintl-8.dll and 
friends).

I also can't have
   "C:/cygwin17/usr/bin/bash -e somescript"
or even
   "cmd /k C:/cygwin17/usr/bin/bash.exe -e somescript"
unless my environment settings (either system or personal) force /bin 
into my PATH (otherwise /usr/bin/bash.exe can't find cygwin1.dll).

But I don't WANT cygwin stuff in either of those PATHs, because that 
makes life more difficult when I'm using eclipse with mingw (because 
eclipse defaults to cygwin if it is found in the PATH, grrr), or when 
I'm in "mingw-on-msys" mode.  So, I'm stuck with
   C:/cygwin/bin/run.exe -p /usr/bin:/bin [/usr]/bin/bash.exe -c somescript
(assuming run.exe is one of the lucky few that live in /bin) or
   somebatchfile.bat
where somebatchfile.bat sets the PATH then invokes the "real" script 
using C:\cygwin17\bin\bash.exe.

Ick.

OTOH, this is my existing XEmacs shortcut target:

C:\cygwin\bin\run.exe -p /usr/X11R6/bin:/usr/bin env.exe --unset=DISPLAY 
xemacs

uses run to set PATH (and hide the console), invokes env to make sure 
DISPLAY is not set -- and env then invokes xemacs. This ensures that I 
get the mswin GUI and not the X GUI (it's a relic of my company's 
Rational ClearCase installation policies, which set DISPLAY in the 
system environment where I don't have permissions to remove it).

I guess similar games can be played with other targets, using /bin/run 
and /bin/env. (so, run.exe and env.exe ought to be in /bin)

And besides, WJM.

> Making duplicate copies is asking for trouble.

But in the WJM option, you still have duplicate copies of bash.exe. It's 
just that (a) they are both identical (b) they both require dlls of 
which there are no duplicate copies, only /usr/bin versions.

I guess if (a) and (b) are big enough "plusses" to deal with the 
inevitable FAQs and list chatter driven by the "minus" above...

and the "minus" alluded to upthread: the idea that /bin should be 
populated by stuff that "just works" even if mounts are all screwed up 
and /usr/bin can't be found.  Under the WJM option, that goes out the 
window. If /usr/bin can't be found, bang. you're dead.

>> No, please don't...I like my /desktop mount...
> 
> You don't need fstab to do mounts.  It's always possible to add a mount
> to your .bashrc or something.  That's what you'd do on linux if you
> wanted similar functionality.

I guess. But in the linux case you need root permission to do a 'mount 
--bind' (which is as close to similar semantics as our "user mounts" as 
I can see). But happily on cygwin we don't need admin privs to create 
(user) mounts.

--
Chuck

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Christopher Faylor]

[responding to the thread which started it all]
On Wed, Apr 02, 2008 at 02:35:51PM +0200, Corinna Vinschen wrote:
>- We create a ftp://cygwin.com/pub/cygwin-1.7 dir.
>
>- Under that dir, we create the full release directory structure as it
>  exists in the parallel cygwin dir, except for the "cygwin" itself.

So far so good.

>- All files in the original release dir are hardlinked into their
>  matching spot in the cygwin-1.7 dir.

I don't like hardlinking.  It's too easy to have unintended side
effects.  I think I'd rather just symlink the directories in the new
release area then rm the symlink and create a new directory when it's
time to populate the directory with a 1.7 version.

>- The "cygwin" subdir gets created and filled with only the first Cygwin
>  DLL 1.7.0 tar files.
>
>- Chris starts a second upset which creates the setup.ini file in
>  the cygwin-1.7 dir.

I can do this but on top of this, I'd actually like to implement my plan
for allowing people to control their own directories.  I hadn't thought
about adding a 1.7 directory but it should still be doable.

If we don't do this, I think we'll be awash in a sea of RFU's and me
pulling what little hair I have left out over upset errors.

I'd also like to finally have a package lint program which could be
invoked automatically.  Anyone want to write one of those?

I don't want to necessarily gate 1.7 on these things but a package lint
is really long overdue, IMO.  You could even write one that took a
setup.ini as input to make sure that the setup.hint was correct to help
stem the tide of upset errors.

cgf

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Christopher Faylor]

On Thu, Apr 03, 2008 at 05:22:51PM -0600, Warren Young wrote:
> Corinna Vinschen wrote:
>>>        /etc/fstab - Yes and get rid of the registry entirely
>> ACK.
>
> Upgrading pain could be eased if setup.exe (or a postinstall script, 
> perhaps) detected that /etc/fstab doesn't exist, and created it from the 
> registry entries.

Yes.  I think that is the intent.

cgf

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Christopher Faylor]

On Thu, Apr 03, 2008 at 06:01:37PM -0500, Charles Wilson wrote:
> Corinna Vinschen wrote:
>> On Apr  3 09:56, Christopher Faylor wrote:
>>> For 1.7, I think we ought to decouple /bin <> /usr/bin and /lib <>
>>> /usr/lib.  The rationale for keeping those linked no longer applies in
>>> the modern setup.exe world.
>> Full ACK!  However, this needs a bit of careful revisiting of some of
>> the packages.  For instance, assuming the Cygwin DLL will go to /bin,
>> cygrunsrv should also reside in /bin when we do this, not in /usr/bin,
>> obviously.  Right now I must admit that I prectically don't care if my
>> packages install the binaries in /bin or /usr/bin.
>
> Yep. A few things off the top of my head:
>
> 1) the shells need to install both in /bin and /usr/bin. This is up to the 
> individual maintainers when they build their -1.7 versions, but to take on 
> super-duper important shell:
> Or "tough. you want to run /bin/bash, ensure /usr/bin is in your PATH"

Yes.  Making duplicate copies is asking for trouble.

> 2) build tools (netrel, gbs, cygport) might need a few additions/tweaks to 
> support any of the above.
>
>> I don't know.  I assume I just took this as it is.  I guess the
>> only reason to create user mounts to begin with was, so that any
>> non-privileged user can create mount points, too, for a pure
>> "just me" installation in a restricted environment.
>> However, that's not really necessary anymore with /etc/fstab.
>> So I agree, we can simply get rid of fstab.$SID.
>
> No, please don't...I like my /desktop mount...

You don't need fstab to do mounts.  It's always possible to add a mount
to your .bashrc or something.  That's what you'd do on linux if you
wanted similar functionality.

cgf

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Warren Young]

Corinna Vinschen wrote:
>>        /etc/fstab - Yes and get rid of the registry entirely
> 
> ACK.

Upgrading pain could be eased if setup.exe (or a postinstall script, 
perhaps) detected that /etc/fstab doesn't exist, and created it from the 
registry entries.

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Charles Wilson]

Igor Peshansky wrote:

> So would it make sense to put the root mount info in the same directory as
> cygwin1.dll?  I know it doesn't belong in /bin, but playing with relative
> paths is even more error-prone.

MSYS has been doing the "find msys dll, then locate ../../etc/fstab" 
thing for years. Of all the (many) problems MSYS has, AFAIK this 
"error-prone" issue has NEVER been one of them.

> /bin should contain programs that should work even if the PATH and mounts
> are screwed up.  So, "kill", "shutdown", etc.

But if THAT is the requirement (work if mounts are messed up and -- for 
instance -- /usr/bin/ can't be found), then they all need to be 
statically linked (with the exception of /bin/cygwin1.dll, of course) -- 
or some carefully selected set of DLLs need to be installed in /bin.

--
Chuck

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Charles Wilson]

Corinna Vinschen wrote:
> On Apr  3 09:56, Christopher Faylor wrote:
>> For 1.7, I think we ought to decouple /bin <> /usr/bin and /lib <>
>> /usr/lib.  The rationale for keeping those linked no longer applies in
>> the modern setup.exe world.
> 
> Full ACK!  However, this needs a bit of careful revisiting of some of
> the packages.  For instance, assuming the Cygwin DLL will go to /bin,
> cygrunsrv should also reside in /bin when we do this, not in /usr/bin,
> obviously.  Right now I must admit that I prectically don't care if my
> packages install the binaries in /bin or /usr/bin.

Yep. A few things off the top of my head:

1) the shells need to install both in /bin and /usr/bin. This is up to 
the individual maintainers when they build their -1.7 versions, but to 
take on super-duper important shell:

   C:\cygwin/bin\bash.exe
     C:\cygwin/bin\cygwin1.dll
     C:\cygwin/bin\cygintl-8.dll
       C:\cygwin/bin\cygiconv-2.dll
     C:\cygwin/bin\cygreadline6.dll
       C:\cygwin/bin\cygncurses-8.dll

Should /bin/bash be built "statically" (at least with regards 
libintl/libiconv/libreadline/libncurses)?  Should /usr/bin/bash be 
identical to /bin/bash and also built statically? Or should 
bash-3.x.y-z.tar.bz2 for cygwin-1.7 have two separate (and different) 
bash executables in it?

What if that tarball (with different /usr/bin/bash and /bin/bash) is 
unpacked on a system where "legacy" /usr/bin->/bin mounts are present?

Or should some "important" set of DLL libraries be installed into both 
/usr/bin/ and /bin, and then /usr/bin/bash.exe and /bin/bash.exe (and 
/bin/sh.exe) can all be exactly the same, built using dynamic links, 
just as /usr/bin/bash.exe is today?

Or "tough. you want to run /bin/bash, ensure /usr/bin is in your PATH"

2) build tools (netrel, gbs, cygport) might need a few additions/tweaks 
to support any of the above.

> I don't know.  I assume I just took this as it is.  I guess the
> only reason to create user mounts to begin with was, so that any
> non-privileged user can create mount points, too, for a pure
> "just me" installation in a restricted environment.
> 
> However, that's not really necessary anymore with /etc/fstab.
> So I agree, we can simply get rid of fstab.$SID.

No, please don't...I like my /desktop mount...

--
Chuck

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Charles Wilson]

Christopher Faylor wrote:

> Why do we need a fstab.$SID and linux doesn't need this?

Well, I like to create user mounts for each user (Guest, Administrator, 
me) like this:

mount -f -u -b "C:/Documents and Settings/<user>/My Documents" "/mydocs"
mount -f -u -b "C:/Documents and Settings/<user>/Desktop" "/desktop"

mainly for convenience, but also because spaces and the command line 
don't mix well. Linux doesn't have to deal with asinine decisions made 
in Redmond, WA...from a hidden microphone in 1995: "LOOK! We can support 
spaces in filenames as well as filenames longer than 8.3, so let's use 
them EVERYWHERE! Spaces for EVERYBODY! Really long and hard to type 
system paths, like 'Documents and Settings'! Whoo-pee!! Steve Jobs has 
got nuthin' on us!"


I realize that on (clean-install, non-upgrade) Vista, this is less of an 
issue, because the "new" paths are

mount -f -u -b "C:/Users/<user>/Documents" "/mydocs"
mount -f -u -b "C:/Users/<user>/Desktop" "/desktop"

but XP and 2k aren't going anywhere for a long long time, if even one of 
the horror stories I've read about Vista are true...

--
Chuck

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Corinna Vinschen]

On Apr  3 12:59, Christopher Faylor wrote:
> On Thu, Apr 03, 2008 at 06:26:46PM +0200, Corinna Vinschen wrote:
> >On Apr  3 12:11, Christopher Faylor wrote:
> >> On Thu, Apr 03, 2008 at 04:19:58PM +0200, Corinna Vinschen wrote:
> >> >Do you think that / should be free as today:
> >> >
> >> >  C:\arbitrary\useless\new\path / ntfs binary 0 0
> >> >
> >> >or do you think an automatic approach as the above
> >> >
> >> >  root / ntfs binary 0 0
> >> >
> >> >is the way to go?  As for cygdrives, isn't the
> >> >
> >> >  cygdrive /mnt auto binary 0 0 
> >> >
> >> >already along the lines of an automount?!?
> >> 
> >> "auto" in /etc/fstab doesn't mean "automount".  It means that it is
> >> meant to be "auto"matically mounted at "boot time".  That's fine for /, /bin, /usr/bin.
> >> It isn't fine for z: where z: is a usb device.
> >
> >Uh, that's something I didn't look for.  I just used the word "auto"
> >because it sounded nice at this point.  Actually the third field
> >is ignored.  The important part is the "cygdrive" in the first field,
> >which is along the lines of, say, "proc" or "sysfs" in Linux.  We
> >don't have a reason (so far) to care for the FS type field in fstab.
> 
> But if we were doing this the "right way" then I think we probably
> should have a procfs and something else which allowed the automatic
> mounting of devices like floppies or usb disks.

I see.  I did the evaluation of a mount point being something automatic
by using a string in the first field, but actually we should use
specific strings in the FS type field and either ignore the content of
the first field - for FS types like "cygdrive", "proc" (later) "root",
"sysfs" (much later) - or the first field is the device which gets mounted
in the second dir if the mount point is "auto".  Sort of a better cygdrive.
I'll change the fstab stuff to do the FS type recognition for cygdrive
and root.  We can then add the "auto" and "proc" stuff easily at some
later point.


Corinna

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

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Christopher Faylor]

On Thu, Apr 03, 2008 at 06:26:46PM +0200, Corinna Vinschen wrote:
>On Apr  3 12:11, Christopher Faylor wrote:
>> On Thu, Apr 03, 2008 at 04:19:58PM +0200, Corinna Vinschen wrote:
>> >Do you think that / should be free as today:
>> >
>> >  C:\arbitrary\useless\new\path / ntfs binary 0 0
>> >
>> >or do you think an automatic approach as the above
>> >
>> >  root / ntfs binary 0 0
>> >
>> >is the way to go?  As for cygdrives, isn't the
>> >
>> >  cygdrive /mnt auto binary 0 0 
>> >
>> >already along the lines of an automount?!?
>> 
>> "auto" in /etc/fstab doesn't mean "automount".  It means that it is
>> meant to be "auto"matically mounted at "boot time".  That's fine for /, /bin, /usr/bin.
>> It isn't fine for z: where z: is a usb device.
>
>Uh, that's something I didn't look for.  I just used the word "auto"
>because it sounded nice at this point.  Actually the third field
>is ignored.  The important part is the "cygdrive" in the first field,
>which is along the lines of, say, "proc" or "sysfs" in Linux.  We
>don't have a reason (so far) to care for the FS type field in fstab.

But if we were doing this the "right way" then I think we probably
should have a procfs and something else which allowed the automatic
mounting of devices like floppies or usb disks.

cgf

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Corinna Vinschen]

On Apr  3 12:11, Christopher Faylor wrote:
> On Thu, Apr 03, 2008 at 04:19:58PM +0200, Corinna Vinschen wrote:
> >Do you think that / should be free as today:
> >
> >  C:\arbitrary\useless\new\path / ntfs binary 0 0
> >
> >or do you think an automatic approach as the above
> >
> >  root / ntfs binary 0 0
> >
> >is the way to go?  As for cygdrives, isn't the
> >
> >  cygdrive /mnt auto binary 0 0 
> >
> >already along the lines of an automount?!?
> 
> "auto" in /etc/fstab doesn't mean "automount".  It means that it is
> meant to be "auto"matically mounted at "boot time".  That's fine for /, /bin, /usr/bin.
> It isn't fine for z: where z: is a usb device.

Uh, that's something I didn't look for.  I just used the word "auto"
because it sounded nice at this point.  Actually the third field
is ignored.  The important part is the "cygdrive" in the first field,
which is along the lines of, say, "proc" or "sysfs" in Linux.  We
don't have a reason (so far) to care for the FS type field in fstab.

> >> >Another problem is that the 1.7 mount(1) still creates the mount entries
> >> >in the registry.  This should be removed, if we stick to the file based
> >> >approach.  mount would only create temporary mount points which are
> >> >only valid in this single session, until the last Cygwin process in this
> >> >session exits.  A bit like a reboot on Linux :)
> >> 
> >> On XP it should be possible to make it so that the mounts last until
> >> reboot.  If we can do that I think it would be ideal.
> >
> >How?  The mount points are bound to the existance of the shared
> >memory they reside in.  This shared mem disappears when the last
> >Cygwin process in a session exits.
> 
> I have to research what I'm thinking of but I think it's possible.  I don't
> know if it is possible for a non-privileged user though.

If you mean to create permanent shared objects, that's not possible for
an admin user either without tweaking the security policy.  This policy
is by default only active for kernel mode code.


Corinna

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

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Christopher Faylor]

On Thu, Apr 03, 2008 at 04:19:58PM +0200, Corinna Vinschen wrote:
>On Apr  3 09:56, Christopher Faylor wrote:
>> On Thu, Apr 03, 2008 at 11:42:20AM +0200, Corinna Vinschen wrote:
>> >    - Do we drop registry mount points and store mount points in future
>> >      in fstab-like files as, say, /etc/fstab (system mount points) and
>> >      ~/.fstab (user mount points)?
>> >
>> >Having said that...
>> 
>> FWIW:  ~/.fstab - No
>
>I don't think that's as easily implementable as having such a file
>in /etc anyway, but you're making an important note below, so, see
>there.
>
>>        /etc/fstab - Yes and get rid of the registry entirely
>
>ACK.
>
>The reason I implemented this with using the registry as a fallback
>is for easier testing.  The idea is that we (developers and maintainers)
>can start to use the fstab approach, while normal users on the Cygwin
>list, who are just curious, still can run a snapshot in their otherwise
>unchanged environment.
>
>> >On Apr  2 17:56, Charles Wilson wrote:
>> >> Corinna Vinschen wrote:
>> >>>   Get own path   ==> C:\\cygwin\\bin\\cygwin1.dll
>> >>>   Where's fstab? ==> C:\\cygwin\\etc\\fstab
>> >>
>> >> So, it implicitly computes where / is?
>> >
>> >No, it doesn't.  It just snips away the last two path components and
>> >tacks the etc/fstab string on.  Plus the .$SID to get the user mounts.
>> >
>> >After the mount points have been read, root can potentially be
>> >somewhere else entirely.
>> 
>> I think that's the right way to handle this.
>
>That puzzles me a bit, because of what you write below.
>
>> >>> these are my fstab files:
>> >>>   $ cat /etc/fstab
>> >>>   C:\cygwin / ntfs binary 0 0
>> >>
>> >> Which means that the line above really ought to match the computed '/', or 
>> >> bad things might happen, right? If so, then it is redundant to specify it 
>> >> here. Perhaps this should just be autocomputed...since the fstype and last 
>> >> two elements are ignored.
>> >
>> >Yes, I thought about this, too.  It doesn't really seem to make much
>> >sense to redefine /.  As for /usr/bin and /usr/lib, these paths are
>> >not inherently defined by the DLL.  They exist because a decision
>> >has been made how to create a Cygwin installation in the net distro.
>> >This could be changed in future, or our internal Red Hat release
>> >could need another layout.  There's no reason to couple this distro
>> >decision to the DLL, IMHO.
>> 
>> For 1.7, I think we ought to decouple /bin <> /usr/bin and /lib <>
>> /usr/lib.  The rationale for keeping those linked no longer applies in
>> the modern setup.exe world.
>
>Full ACK!  However, this needs a bit of careful revisiting of some of
>the packages.  For instance, assuming the Cygwin DLL will go to /bin,
>cygrunsrv should also reside in /bin when we do this, not in /usr/bin,
>obviously.  Right now I must admit that I prectically don't care if my
>packages install the binaries in /bin or /usr/bin.
>
>> >Or simply
>> >
>> >    root / ntfs binary 0 0
>> >
>> >and stick to /usr/bin and /usr/lib as they are today.
>> 
>> I think something like an automount is needed since it would be nice to
>> eventually generalize the cygdrive stuff and we don't want to explicitly
>> mount a: - z: So, maybe we could consider a linux-like solution to
>> accomplish this although I really don't like automount.
>
>I'm not sure I understand this, that's why I was puzzled above.
>Do you think that / should be free as today:
>
>  C:\arbitrary\useless\new\path / ntfs binary 0 0
>
>or do you think an automatic approach as the above
>
>  root / ntfs binary 0 0
>
>is the way to go?  As for cygdrives, isn't the
>
>  cygdrive /mnt auto binary 0 0 
>
>already along the lines of an automount?!?

"auto" in /etc/fstab doesn't mean "automount".  It means that it is
meant to be "auto"matically mounted at "boot time".  That's fine for /, /bin, /usr/bin.
It isn't fine for z: where z: is a usb device.

>> >Another problem is that the 1.7 mount(1) still creates the mount entries
>> >in the registry.  This should be removed, if we stick to the file based
>> >approach.  mount would only create temporary mount points which are
>> >only valid in this single session, until the last Cygwin process in this
>> >session exits.  A bit like a reboot on Linux :)
>> 
>> On XP it should be possible to make it so that the mounts last until
>> reboot.  If we can do that I think it would be ideal.
>
>How?  The mount points are bound to the existance of the shared
>memory they reside in.  This shared mem disappears when the last
>Cygwin process in a session exits.

I have to research what I'm thinking of but I think it's possible.  I don't
know if it is possible for a non-privileged user though.

cgf

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Corinna Vinschen]

On Apr  3 17:38, Corinna Vinschen wrote:
> On Apr  3 11:16, Igor Peshansky wrote:
> > On Thu, 3 Apr 2008, Corinna Vinschen wrote:
> > > [snip]
> > > > >>>   Get own path   ==> C:\\cygwin\\bin\\cygwin1.dll
> > > > >>>   Where's fstab? ==> C:\\cygwin\\etc\\fstab
> > > > >>
> > > > >> So, it implicitly computes where / is?
> > > > >
> > > > >No, it doesn't.  It just snips away the last two path components and
> > > > >tacks the etc/fstab string on.  Plus the .$SID to get the user mounts.
> > > > >
> > > > >After the mount points have been read, root can potentially be
> > > > >somewhere else entirely.
> > 
> > So would it make sense to put the root mount info in the same directory as
> > cygwin1.dll?  I know it doesn't belong in /bin, but playing with relative
> > paths is even more error-prone.
> 
> I don't understand this.  As discussed somewhat later, if the root dir
> follows automatically from where the DLL itself resides.  Which, btw.,
> [...]

Looks like I distracted myself while replying.

What I was trying to say is, if the root dir is taken automatically
from the path of the DLL, there is no reason to have the path to the 
root dir stored anywhere, isn't it?


Corinna

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

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Corinna Vinschen]

[#$%^!  I had a reply-to set in my original reply.  I removed it.
 Please reply to *this* mail.  Thanks.]



On Apr  3 11:16, Igor Peshansky wrote:
> On Thu, 3 Apr 2008, Corinna Vinschen wrote:
> > [snip]
> > > >>>   Get own path   ==> C:\\cygwin\\bin\\cygwin1.dll
> > > >>>   Where's fstab? ==> C:\\cygwin\\etc\\fstab
> > > >>
> > > >> So, it implicitly computes where / is?
> > > >
> > > >No, it doesn't.  It just snips away the last two path components and
> > > >tacks the etc/fstab string on.  Plus the .$SID to get the user mounts.
> > > >
> > > >After the mount points have been read, root can potentially be
> > > >somewhere else entirely.
> 
> So would it make sense to put the root mount info in the same directory as
> cygwin1.dll?  I know it doesn't belong in /bin, but playing with relative
> paths is even more error-prone.

I don't understand this.  As discussed somewhat later, if the root dir
follows automatically from where the DLL itself resides.  Which, btw.,
the current code doesn't do right.  I called GetModuleFileName(NULL)
which returns the path of the current application, not the path of the
Cygwin DLL.  I'll fix that.

> > [snip]
> > > For 1.7, I think we ought to decouple /bin <> /usr/bin and /lib <>
> > > /usr/lib.  The rationale for keeping those linked no longer applies in
> > > the modern setup.exe world.
> >
> > Full ACK!  However, this needs a bit of careful revisiting of some of
> > the packages.  For instance, assuming the Cygwin DLL will go to /bin,
> > cygrunsrv should also reside in /bin when we do this, not in /usr/bin,
> > obviously.
> 
> Umm, i don't see how that follows.  cygrunsrv can easily reside in
> /usr/bin, as long as (a) /bin is in the PATH when cygrunsrv is invoked
> from the shell, and (b) when cygrunsrv installs the services, it adds /bin
> to the PATH in the service environment.

Which is too late for cygrunsrv itself, right?  The idea is to avoid
having to add the Cygwin bin dir to the system variable %PATH%.  If you
want to accomplish that, cygrunsrv itself must be independent of it.
That's only the case if it shares the bin dir with the Cygwin DLL.

> > Right now I must admit that I prectically don't care if my packages
> > install the binaries in /bin or /usr/bin.
> 
> /bin should contain programs that should work even if the PATH and mounts
> are screwed up.  So, "kill", "shutdown", etc.

And cygrunsrv.

> > However, that's not really necessary anymore with /etc/fstab.
> > So I agree, we can simply get rid of fstab.$SID.
> 
> Yes, that reasoning is mostly correct.  However, some packages (like
> Cygwin/X) apparently assume a single-user installation, and create
> sockets/temp files in shared locations (i.e., /tmp).  That, unfortunately,

That's a bug in Cygwin/X or in using it.  If you have different DISPLAY
numbers for different displays, they shouldn't share the /tmp stuff,
just like on Linux et al.


Corinna

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

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Corinna Vinschen]

On Apr  3 11:16, Igor Peshansky wrote:
> On Thu, 3 Apr 2008, Corinna Vinschen wrote:
> > [snip]
> > > >>>   Get own path   ==> C:\\cygwin\\bin\\cygwin1.dll
> > > >>>   Where's fstab? ==> C:\\cygwin\\etc\\fstab
> > > >>
> > > >> So, it implicitly computes where / is?
> > > >
> > > >No, it doesn't.  It just snips away the last two path components and
> > > >tacks the etc/fstab string on.  Plus the .$SID to get the user mounts.
> > > >
> > > >After the mount points have been read, root can potentially be
> > > >somewhere else entirely.
> 
> So would it make sense to put the root mount info in the same directory as
> cygwin1.dll?  I know it doesn't belong in /bin, but playing with relative
> paths is even more error-prone.

I don't understand this.  As discussed somewhat later, if the root dir
follows automatically from where the DLL itself resides.  Which, btw.,
the current code doesn't do right.  I called GetModuleFileName(NULL)
which returns the path of the current application, not the path of the
Cygwin DLL.  I'll fix that.

> > [snip]
> > > For 1.7, I think we ought to decouple /bin <> /usr/bin and /lib <>
> > > /usr/lib.  The rationale for keeping those linked no longer applies in
> > > the modern setup.exe world.
> >
> > Full ACK!  However, this needs a bit of careful revisiting of some of
> > the packages.  For instance, assuming the Cygwin DLL will go to /bin,
> > cygrunsrv should also reside in /bin when we do this, not in /usr/bin,
> > obviously.
> 
> Umm, i don't see how that follows.  cygrunsrv can easily reside in
> /usr/bin, as long as (a) /bin is in the PATH when cygrunsrv is invoked
> from the shell, and (b) when cygrunsrv installs the services, it adds /bin
> to the PATH in the service environment.

Which is too late for cygrunsrv itself, right?  The idea is to avoid
having to add the Cygwin bin dir to the system variable %PATH%.  If you
want to accomplish that, cygrunsrv itself must be independent of it.
That's only the case if it shares the bin dir with the Cygwin DLL.

> > Right now I must admit that I prectically don't care if my packages
> > install the binaries in /bin or /usr/bin.
> 
> /bin should contain programs that should work even if the PATH and mounts
> are screwed up.  So, "kill", "shutdown", etc.

And cygrunsrv.

> > However, that's not really necessary anymore with /etc/fstab.
> > So I agree, we can simply get rid of fstab.$SID.
> 
> Yes, that reasoning is mostly correct.  However, some packages (like
> Cygwin/X) apparently assume a single-user installation, and create
> sockets/temp files in shared locations (i.e., /tmp).  That, unfortunately,

That's a bug in Cygwin/X or in using it.  If you have different DISPLAY
numbers for different displays, they shouldn't share the /tmp stuff,
just like on Linux et al.


Corinna

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

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Igor Peshansky]

On Thu, 3 Apr 2008, Corinna Vinschen wrote:

> [snip]
> > >>>   Get own path   ==> C:\\cygwin\\bin\\cygwin1.dll
> > >>>   Where's fstab? ==> C:\\cygwin\\etc\\fstab
> > >>
> > >> So, it implicitly computes where / is?
> > >
> > >No, it doesn't.  It just snips away the last two path components and
> > >tacks the etc/fstab string on.  Plus the .$SID to get the user mounts.
> > >
> > >After the mount points have been read, root can potentially be
> > >somewhere else entirely.

So would it make sense to put the root mount info in the same directory as
cygwin1.dll?  I know it doesn't belong in /bin, but playing with relative
paths is even more error-prone.

> [snip]
> > For 1.7, I think we ought to decouple /bin <> /usr/bin and /lib <>
> > /usr/lib.  The rationale for keeping those linked no longer applies in
> > the modern setup.exe world.
>
> Full ACK!  However, this needs a bit of careful revisiting of some of
> the packages.  For instance, assuming the Cygwin DLL will go to /bin,
> cygrunsrv should also reside in /bin when we do this, not in /usr/bin,
> obviously.

Umm, i don't see how that follows.  cygrunsrv can easily reside in
/usr/bin, as long as (a) /bin is in the PATH when cygrunsrv is invoked
from the shell, and (b) when cygrunsrv installs the services, it adds /bin
to the PATH in the service environment.

> Right now I must admit that I prectically don't care if my packages
> install the binaries in /bin or /usr/bin.

/bin should contain programs that should work even if the PATH and mounts
are screwed up.  So, "kill", "shutdown", etc.

> > >Or simply
> > >
> > >    root / ntfs binary 0 0
> > >
> > >and stick to /usr/bin and /usr/lib as they are today.
> >
> > I think something like an automount is needed since it would be nice
> > to eventually generalize the cygdrive stuff and we don't want to
> > explicitly mount a: - z: So, maybe we could consider a linux-like
> > solution to accomplish this although I really don't like automount.
>
> I'm not sure I understand this, that's why I was puzzled above.
> Do you think that / should be free as today:
>
>   C:\arbitrary\useless\new\path / ntfs binary 0 0
>
> or do you think an automatic approach as the above
>
>   root / ntfs binary 0 0
>
> is the way to go?  As for cygdrives, isn't the
>
>   cygdrive /mnt auto binary 0 0
>
> already along the lines of an automount?!?

It is, IMHO.

> > >I have the vague feeling it would be sufficient to install only a
> > >/etc/fstab, even in "just me" mode, though.  The fstab.$SID file is
> > >only necessary in multi-user installations, IMHO.
> >
> > Why do we need a fstab.$SID and linux doesn't need this?
>
> Let me think...
>
> I don't know.  I assume I just took this as it is.  I guess the
> only reason to create user mounts to begin with was, so that any
> non-privileged user can create mount points, too, for a pure
> "just me" installation in a restricted environment.

That, and also to allow completely disjoint Cygwin installations for
different users (where the mount table would otherwise be shared).  But
this effect can also be accomplished with /etc/fstab (one per
installation).

> However, that's not really necessary anymore with /etc/fstab.
> So I agree, we can simply get rid of fstab.$SID.

Yes, that reasoning is mostly correct.  However, some packages (like
Cygwin/X) apparently assume a single-user installation, and create
sockets/temp files in shared locations (i.e., /tmp).  That, unfortunately,
makes the default startup scripts insufficient to allow multiple users to
run Cygwin/X sessions simultaneously, unless that shared location is
overridden in a per-user manner (e.g., through user mounts).  So, until we
figure out how to solve that issue, user mounts are actually userful.
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_	    pechtcha@cs.nyu.edu | igor@watson.ibm.com
ZZZzz /,`.-'`'    -.  ;-;;,_		Igor Peshansky, Ph.D. (name changed!)
     |,4-  ) )-,_. ,\ (  `'-'		old name: Igor Pechtchanski
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"That which is hateful to you, do not do to your neighbor.  That is the whole
Torah; the rest is commentary.  Go and study it." -- Rabbi Hillel

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Corinna Vinschen]

On Apr  3 09:56, Christopher Faylor wrote:
> On Thu, Apr 03, 2008 at 11:42:20AM +0200, Corinna Vinschen wrote:
> >    - Do we drop registry mount points and store mount points in future
> >      in fstab-like files as, say, /etc/fstab (system mount points) and
> >      ~/.fstab (user mount points)?
> >
> >Having said that...
> 
> FWIW:  ~/.fstab - No

I don't think that's as easily implementable as having such a file
in /etc anyway, but you're making an important note below, so, see
there.

>        /etc/fstab - Yes and get rid of the registry entirely

ACK.

The reason I implemented this with using the registry as a fallback
is for easier testing.  The idea is that we (developers and maintainers)
can start to use the fstab approach, while normal users on the Cygwin
list, who are just curious, still can run a snapshot in their otherwise
unchanged environment.

> >On Apr  2 17:56, Charles Wilson wrote:
> >> Corinna Vinschen wrote:
> >>>   Get own path   ==> C:\\cygwin\\bin\\cygwin1.dll
> >>>   Where's fstab? ==> C:\\cygwin\\etc\\fstab
> >>
> >> So, it implicitly computes where / is?
> >
> >No, it doesn't.  It just snips away the last two path components and
> >tacks the etc/fstab string on.  Plus the .$SID to get the user mounts.
> >
> >After the mount points have been read, root can potentially be
> >somewhere else entirely.
> 
> I think that's the right way to handle this.

That puzzles me a bit, because of what you write below.

> >>> these are my fstab files:
> >>>   $ cat /etc/fstab
> >>>   C:\cygwin / ntfs binary 0 0
> >>
> >> Which means that the line above really ought to match the computed '/', or 
> >> bad things might happen, right? If so, then it is redundant to specify it 
> >> here. Perhaps this should just be autocomputed...since the fstype and last 
> >> two elements are ignored.
> >
> >Yes, I thought about this, too.  It doesn't really seem to make much
> >sense to redefine /.  As for /usr/bin and /usr/lib, these paths are
> >not inherently defined by the DLL.  They exist because a decision
> >has been made how to create a Cygwin installation in the net distro.
> >This could be changed in future, or our internal Red Hat release
> >could need another layout.  There's no reason to couple this distro
> >decision to the DLL, IMHO.
> 
> For 1.7, I think we ought to decouple /bin <> /usr/bin and /lib <>
> /usr/lib.  The rationale for keeping those linked no longer applies in
> the modern setup.exe world.

Full ACK!  However, this needs a bit of careful revisiting of some of
the packages.  For instance, assuming the Cygwin DLL will go to /bin,
cygrunsrv should also reside in /bin when we do this, not in /usr/bin,
obviously.  Right now I must admit that I prectically don't care if my
packages install the binaries in /bin or /usr/bin.

> >Or simply
> >
> >    root / ntfs binary 0 0
> >
> >and stick to /usr/bin and /usr/lib as they are today.
> 
> I think something like an automount is needed since it would be nice to
> eventually generalize the cygdrive stuff and we don't want to explicitly
> mount a: - z: So, maybe we could consider a linux-like solution to
> accomplish this although I really don't like automount.

I'm not sure I understand this, that's why I was puzzled above.
Do you think that / should be free as today:

  C:\arbitrary\useless\new\path / ntfs binary 0 0

or do you think an automatic approach as the above

  root / ntfs binary 0 0

is the way to go?  As for cygdrives, isn't the

  cygdrive /mnt auto binary 0 0 

already along the lines of an automount?!?

> >I have the vague feeling it would be sufficient to install only a
> >/etc/fstab, even in "just me" mode, though.  The fstab.$SID file is
> >only necessary in multi-user installations, IMHO.
> 
> Why do we need a fstab.$SID and linux doesn't need this?

Let me think...

I don't know.  I assume I just took this as it is.  I guess the
only reason to create user mounts to begin with was, so that any
non-privileged user can create mount points, too, for a pure
"just me" installation in a restricted environment.

However, that's not really necessary anymore with /etc/fstab.
So I agree, we can simply get rid of fstab.$SID.

> >Another problem is that the 1.7 mount(1) still creates the mount entries
> >in the registry.  This should be removed, if we stick to the file based
> >approach.  mount would only create temporary mount points which are
> >only valid in this single session, until the last Cygwin process in this
> >session exits.  A bit like a reboot on Linux :)
> 
> On XP it should be possible to make it so that the mounts last until
> reboot.  If we can do that I think it would be ideal.

How?  The mount points are bound to the existance of the shared
memory they reside in.  This shared mem disappears when the last
Cygwin process in a session exits.


Corinna

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

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Christopher Faylor]

On Thu, Apr 03, 2008 at 11:42:20AM +0200, Corinna Vinschen wrote:
>For a start, please note that this patch is just preliminary.
>
>The actual problem is still one of the problems I noted in my mail
>http://cygwin.com/ml/cygwin-developers/2008-03/msg00000.html, to which I
>didn't get a reply, except from Brian.
>
>  - The POSIX path of mount points is restricted to 256 characters.
>    That's because it's used as the value name of a registry value and
>    value names are restricted to (surprise!) 256 chars.  A decision
>    and, perhaps, coding has to be done:
>
>    - Do we stick to this restriction?
>    - Do we introduce a new mount point storage in the registry?
>    - Do we drop registry mount points and store mount points in future
>      in fstab-like files as, say, /etc/fstab (system mount points) and
>      ~/.fstab (user mount points)?
>
>Having said that...

FWIW:  ~/.fstab - No
       /etc/fstab - Yes and get rid of the registry entirely

>On Apr  2 17:56, Charles Wilson wrote:
>> Corinna Vinschen wrote:
>>> I have applied a preliminary patch to Cygwin which allows to load the
>>> mount entries from /etc/fstab and /etc/fstab.<usersid>.  If none of
>>> these files is available, the DLL falls back to reading the mount points
>>> from the registry.
>>
>> I like this.  A lot.
>
>AOL ;)
>
>>> Cygwin finds the fstab files by fetching it's own Win32 path and then
>>> replacing the last two path components with etc/fstab or
>>> etc/fstab.<usersid>, like this:
>>>   Get own path   ==> C:\\cygwin\\bin\\cygwin1.dll
>>>   Where's fstab? ==> C:\\cygwin\\etc\\fstab
>>
>> So, it implicitly computes where / is?
>
>No, it doesn't.  It just snips away the last two path components and
>tacks the etc/fstab string on.  Plus the .$SID to get the user mounts.
>
>After the mount points have been read, root can potentially be
>somewhere else entirely.

I think that's the right way to handle this.

>>> The layout of the fstab file follows the Linux layout.  As example,
>>> these are my fstab files:
>>>   $ cat /etc/fstab
>>>   C:\cygwin / ntfs binary 0 0
>>
>> Which means that the line above really ought to match the computed '/', or 
>> bad things might happen, right? If so, then it is redundant to specify it 
>> here. Perhaps this should just be autocomputed...since the fstype and last 
>> two elements are ignored.
>
>Yes, I thought about this, too.  It doesn't really seem to make much
>sense to redefine /.  As for /usr/bin and /usr/lib, these paths are
>not inherently defined by the DLL.  They exist because a decision
>has been made how to create a Cygwin installation in the net distro.
>This could be changed in future, or our internal Red Hat release
>could need another layout.  There's no reason to couple this distro
>decision to the DLL, IMHO.

For 1.7, I think we ought to decouple /bin <> /usr/bin and /lib <>
/usr/lib.  The rationale for keeping those linked no longer applies in
the modern setup.exe world.


>> [...]
>> Maybe there should be "special" rules for the three special autocomputed 
>> mount points:
>>
>>    # NOTE: the three "magic" auto-computed paths are present
>>    # in this file strictly so that mount options may be specified.
>>    C:\This\Path\Is\AutoComputed /        ntfs binary 0 0
>>    C:\This\Path\Is\AutoComputed /usr/bin ntfs binary 0 0
>>    C:\This\Path\Is\AutoComputed /usr/lib ntfs binary 0 0
>
>Or simply
>
>    root / ntfs binary 0 0
>
>and stick to /usr/bin and /usr/lib as they are today.

I think something like an automount is needed since it would be nice to
eventually generalize the cygdrive stuff and we don't want to explicitly
mount a: - z: So, maybe we could consider a linux-like solution to
accomplish this although I really don't like automount.

>> Oh, and I'm guessing that setup-1.7 should create /etc/fstab if "install 
>> for all users", and "/etc/fstab.SID" if "just me"?  Otherwise, you'll 
>> clobber the "old" cygwin's registry entries every time you try to update 
>> your "new" cygwin installation...
>
>That's right.  I think this could be done by a simple postinstall script
>which gets called from setup-1.7.  Consider a package which comes with
>a default /etc/fstab which consists only of the above entry for the root
>dir.  The script would simply add the /usr/bin and /usr/lib entries.
>I have the vague feeling it would be sufficient to install only a
>/etc/fstab, even in "just me" mode, though.  The fstab.$SID file is
>only necessary in multi-user installations, IMHO.

Why do we need a fstab.$SID and linux doesn't need this?

>Another problem is that the 1.7 mount(1) still creates the mount entries
>in the registry.  This should be removed, if we stick to the file based
>approach.  mount would only create temporary mount points which are
>only valid in this single session, until the last Cygwin process in this
>session exits.  A bit like a reboot on Linux :)

On XP it should be possible to make it so that the mounts last until
reboot.  If we can do that I think it would be ideal.

cgf

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Corinna Vinschen]

For a start, please note that this patch is just preliminary.

The actual problem is still one of the problems I noted in my mail
http://cygwin.com/ml/cygwin-developers/2008-03/msg00000.html, to which I
didn't get a reply, except from Brian.

  - The POSIX path of mount points is restricted to 256 characters.
    That's because it's used as the value name of a registry value and
    value names are restricted to (surprise!) 256 chars.  A decision
    and, perhaps, coding has to be done:

    - Do we stick to this restriction?
    - Do we introduce a new mount point storage in the registry?
    - Do we drop registry mount points and store mount points in future
      in fstab-like files as, say, /etc/fstab (system mount points) and
      ~/.fstab (user mount points)?

Having said that...

On Apr  2 17:56, Charles Wilson wrote:
> Corinna Vinschen wrote:
>> I have applied a preliminary patch to Cygwin which allows to load the
>> mount entries from /etc/fstab and /etc/fstab.<usersid>.  If none of
>> these files is available, the DLL falls back to reading the mount points
>> from the registry.
>
> I like this.  A lot.

AOL ;)

>> Cygwin finds the fstab files by fetching it's own Win32 path and then
>> replacing the last two path components with etc/fstab or
>> etc/fstab.<usersid>, like this:
>>   Get own path   ==> C:\\cygwin\\bin\\cygwin1.dll
>>   Where's fstab? ==> C:\\cygwin\\etc\\fstab
>
> So, it implicitly computes where / is?

No, it doesn't.  It just snips away the last two path components and
tacks the etc/fstab string on.  Plus the .$SID to get the user mounts.

After the mount points have been read, root can potentially be
somewhere else entirely.

>> The layout of the fstab file follows the Linux layout.  As example,
>> these are my fstab files:
>>   $ cat /etc/fstab
>>   C:\cygwin / ntfs binary 0 0
>
> Which means that the line above really ought to match the computed '/', or 
> bad things might happen, right? If so, then it is redundant to specify it 
> here. Perhaps this should just be autocomputed...since the fstype and last 
> two elements are ignored.

Yes, I thought about this, too.  It doesn't really seem to make much
sense to redefine /.  As for /usr/bin and /usr/lib, these paths are
not inherently defined by the DLL.  They exist because a decision
has been made how to create a Cygwin installation in the net distro.
This could be changed in future, or our internal Red Hat release
could need another layout.  There's no reason to couple this distro
decision to the DLL, IMHO.

> [...]
> Maybe there should be "special" rules for the three special autocomputed 
> mount points:
>
>    # NOTE: the three "magic" auto-computed paths are present
>    # in this file strictly so that mount options may be specified.
>    C:\This\Path\Is\AutoComputed /        ntfs binary 0 0
>    C:\This\Path\Is\AutoComputed /usr/bin ntfs binary 0 0
>    C:\This\Path\Is\AutoComputed /usr/lib ntfs binary 0 0

Or simply

    root / ntfs binary 0 0

and stick to /usr/bin and /usr/lib as they are today.

> Oh, and I'm guessing that setup-1.7 should create /etc/fstab if "install 
> for all users", and "/etc/fstab.SID" if "just me"?  Otherwise, you'll 
> clobber the "old" cygwin's registry entries every time you try to update 
> your "new" cygwin installation...

That's right.  I think this could be done by a simple postinstall script
which gets called from setup-1.7.  Consider a package which comes with
a default /etc/fstab which consists only of the above entry for the root
dir.  The script would simply add the /usr/bin and /usr/lib entries.
I have the vague feeling it would be sufficient to install only a
/etc/fstab, even in "just me" mode, though.  The fstab.$SID file is
only necessary in multi-user installations, IMHO.

Another problem is that the 1.7 mount(1) still creates the mount entries
in the registry.  This should be removed, if we stick to the file based
approach.  mount would only create temporary mount points which are
only valid in this single session, until the last Cygwin process in this
session exits.  A bit like a reboot on Linux :)

> One little wrinkle that makes switching between two cygwin installations 
> difficult: services.  Do you
>
>  (1) stop/uninstall -- switch-to-other-cygwin -- reinstall/start as part of 
> each switch, or
>
>  (2) somehow change each service's target path (and PATH environment 
> variable, if the service.exe is not in /bin. For the proposed 1.7.0 you 
> have to ensure that the "correct" cygwin1.dll is used), and then restart?
>
>  (3) install services under different names for the two installations, and 
> just remember to stop all the old ones, before trying to use any tools from 
> the "new" installation, and restart the "new" services under their 
> alternate installation names?  The installation part of this proposal could 
> be automated in the foo-config scripts:
>   if cygwin_17
>   then service_name=sshd_17
>   else service_name=sshd
>   fi
> etc.

Consider that a parallel installation is not really for the normal user.
My answer to this question is, whatever is most convenient for you.
Personally I tend to option 3, without the changes in the foo-config
scripts.  I'd do the second service installation manually.  It's not
that hard.


Corinna

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

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Charles Wilson]

Corinna Vinschen wrote:
> I have applied a preliminary patch to Cygwin which allows to load the
> mount entries from /etc/fstab and /etc/fstab.<usersid>.  If none of
> these files is available, the DLL falls back to reading the mount points
> from the registry.

I like this.  A lot.

> Cygwin finds the fstab files by fetching it's own Win32 path and then
> replacing the last two path components with etc/fstab or
> etc/fstab.<usersid>, like this:
> 
>   Get own path   ==> C:\\cygwin\\bin\\cygwin1.dll
>   Where's fstab? ==> C:\\cygwin\\etc\\fstab

So, it implicitly computes where / is?

> The layout of the fstab file follows the Linux layout.  As example,
> these are my fstab files:
> 
>   $ cat /etc/fstab
>   C:\cygwin / ntfs binary 0 0

Which means that the line above really ought to match the computed '/', 
or bad things might happen, right? If so, then it is redundant to 
specify it here. Perhaps this should just be autocomputed...since the 
fstype and last two elements are ignored.

But that still leaves the mount options. Urk.

>   C:\cygwin\bin /usr/bin ntfs binary 0 0

This is the typical loopback mount /usr/bin from /bin -- but
   a) we have already computed the DOS path of /bin -- that's how we 
figured out where / should be.
   b) We do not support any installation where /usr/bin is NOT a 
loopback on /bin.

So...maybe this entry should be automatic, too?  Except for the mount 
options.

>   C:\cygwin\lib /usr/lib ntfs binary 0 0

Finally, given all of the above...there's an obvious suggestion with 
respect to the /usr/lib loopback mount, as well.  Except for the mount 
options.

Maybe there should be "special" rules for the three special autocomputed 
mount points:

    # NOTE: the three "magic" auto-computed paths are present
    # in this file strictly so that mount options may be specified.
    C:\This\Path\Is\AutoComputed /        ntfs binary 0 0
    C:\This\Path\Is\AutoComputed /usr/bin ntfs binary 0 0
    C:\This\Path\Is\AutoComputed /usr/lib ntfs binary 0 0
    C:\cygwin\usr\X11R6\lib\X11\fonts /usr/X11R6/lib/X11/fonts ntfs 
binary 0 0
    \\fs01\archiv /home/archiv smbfs binary 0 0
    cygdrive /mnt auto binary 0 0


Oh, and I'm guessing that setup-1.7 should create /etc/fstab if "install 
for all users", and "/etc/fstab.SID" if "just me"?  Otherwise, you'll 
clobber the "old" cygwin's registry entries every time you try to update 
your "new" cygwin installation...


=====
One little wrinkle that makes switching between two cygwin installations 
difficult: services.  Do you

  (1) stop/uninstall -- switch-to-other-cygwin -- reinstall/start as 
part of each switch, or

  (2) somehow change each service's target path (and PATH environment 
variable, if the service.exe is not in /bin. For the proposed 1.7.0 you 
have to ensure that the "correct" cygwin1.dll is used), and then restart?

  (3) install services under different names for the two installations, 
and just remember to stop all the old ones, before trying to use any 
tools from the "new" installation, and restart the "new" services under 
their alternate installation names?  The installation part of this 
proposal could be automated in the foo-config scripts:
   if cygwin_17
   then service_name=sshd_17
   else service_name=sshd
   fi
etc.

I'm thinking specifically of the inetd/syslogd/sshd daemons, but also 
cygserver...

--
Chuck

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Corinna Vinschen]

On Apr  2 14:35, Corinna Vinschen wrote:
> Having said that, I would like to ask especially you package maintainers
> to set up a separate machine or a separate cygwin directory for the 1.7
> release.  Right now we have the problem that the mount points in the
> registry are still shared between a 1.5 and a 1.7 release, so you will
> have to create some batch files to switch the mount points between the
> two installations, if you do this on a single machine.  That's a bit of
> a hassle, but it's doable, ok?

I have applied a preliminary patch to Cygwin which allows to load the
mount entries from /etc/fstab and /etc/fstab.<usersid>.  If none of
these files is available, the DLL falls back to reading the mount points
from the registry.

This allows to install a 1.7 Cygwin tree which is independent from a
parallel 1.5.x installation in terms of mount points.  It's still not a
good idea to *run* two parallel DLLs, though.

Cygwin finds the fstab files by fetching it's own Win32 path and then
replacing the last two path components with etc/fstab or
etc/fstab.<usersid>, like this:

  Get own path   ==> C:\\cygwin\\bin\\cygwin1.dll
  Where's fstab? ==> C:\\cygwin\\etc\\fstab

The layout of the fstab file follows the Linux layout.  As example,
these are my fstab files:

  $ cat /etc/fstab
  C:\cygwin / ntfs binary 0 0
  C:\cygwin\bin /usr/bin ntfs binary 0 0
  C:\cygwin\lib /usr/lib ntfs binary 0 0
  C:\cygwin\usr\X11R6\lib\X11\fonts /usr/X11R6/lib/X11/fonts ntfs binary 0 0
  \\fs01\archiv /home/archiv smbfs binary 0 0
  cygdrive /mnt auto binary 0 0

  $ cat /etc/fstab.S-1-5-21-1220945662-261903793-725345543-1003
  C:\cygwin\home\corinna\textmode-dir /home/corinna/textmode-dir ntfs text 0 0
  c:\cygwin\home\corinna\managed /home/corinna/managed ntfs binary,managed 0 0

Leading spaces and tabs are ignored.  Spaces and tabs are field
separators.  Lines starting with a # are skipped.  Maximum line length
is 64K.  Malformed lines are ignored.

First string:    Native path.
		 The special string "cygdrive" allows to specify the
		 cygdrive prefix.
		 Max length 260 bytes for now.

Second string:   POSIX path.  For "cygdrive" the cygdrive prefix.
		 Max length 260 bytes for now.

Thirds string:   FS type, ignored.

Forth string:    Flags list, separated by comma. 
	         Valid flags: binary,text,exec,notexec,cygexec,nosuid,managed.
	         For a description, see Cygwin's `man mount'

Fifth and sixth string: Ignored.


FAQ:  Q: Where do I get my SID from?
      A: See your /etc/passwd entry, the string starting with S-1-.


Corinna

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

[HEADSUP] Let's start a Cygwin 1.7 release area

[Corinna Vinschen]

Hi,

even though Cygwin 1.7 is not yet really ok for a main release, I think
that it's time to start a release area for it, so we can start to build
Cygwin applications specificially for 1.7.  A major advantage is that we
will get much more testing, especially when using features which are not
at all present in 1.5.  Long path names, the LSA module, Linux extended
attributes, Vista symlink support, ... more stuff I just don't remember,
and, last but definitely not least, IPv6 support.
I'm not sure if that's the best way to accomplish this, but here's
my idea how to start:

- We create a ftp://cygwin.com/pub/cygwin-1.7 dir.

- Under that dir, we create the full release directory structure as it
  exists in the parallel cygwin dir, except for the "cygwin" itself.

- All files in the original release dir are hardlinked into their
  matching spot in the cygwin-1.7 dir.

- The "cygwin" subdir gets created and filled with only the first Cygwin
  DLL 1.7.0 tar files.

- Chris starts a second upset which creates the setup.ini file in
  the cygwin-1.7 dir.

- The setup.exe team creates a special setup-1.7.exe which will fetch
  data from the cygwin-1.7 directory.

As soon as a maintainer creates a package which has been build under
1.7.0, this package gets copied into the respective directory under the
cygwin-1.7 hirarchy.  This allows to slowly migrate to the 1.7 release
and especially more and more testing and feedback on bugs.

When we're confident that we can dare the first actual public release of
1.7, many packages will already be available in a 1.7 specific build and
the migration will be more smooth for normal users.

Having said that, I would like to ask especially you package maintainers
to set up a separate machine or a separate cygwin directory for the 1.7
release.  Right now we have the problem that the mount points in the
registry are still shared between a 1.5 and a 1.7 release, so you will
have to create some batch files to switch the mount points between the
two installations, if you do this on a single machine.  That's a bit of
a hassle, but it's doable, ok?

Is there anything wrong or sick with the above procedure?


Corinna

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