This is the mail archive of the cygwin-apps mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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


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


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