[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