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

[Corinna Vinschen <corinna-cygwin@cygwin.com>]

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