This is the mail archive of the
mailing list for the Cygwin project.
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
[#$%^! 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.
> > 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 Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com