This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Thu, 3 Apr 2008, Corinna Vinschen wrote:
> [#$%^! I had a reply-to set in my original reply. I removed it.
> Please reply to *this* mail. Thanks.]
Do you mean this *list*? If not, I'll forward the reply to cygwin-apps as
well...
> 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.
Yes, but the location of /bin doesn't. So, you can end up in a situation
where /etc/fstab contains mounts that point to a /bin directory with
another cygwin1.dll (or, for that matter, an /etc directory with another
fstab).
> 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.
Not really. The PATH I'm talking about is the SCM's notion of PATH, which
will be used to invoke the service executable (cygrunsrv).
I should have been clearer - I didn't mean that cygrunsrv should set the
PATH using setenv when it executes as a service, only that when cygrunsrv
installs itself as a service, it should also set the PATH entry in the
service description.
> > > 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.
As I said above, I don't see why...
> > > 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.
Yes, if the display numbers are different then the sockets are different.
But Linux doesn't have a notion of multiple independent per-user window
stations on the same machine... So either Cygwin/X needs to be more
adapted to Windows than it is now, or we need to make some allowances for
the users to run the pristine Cygwin/X.
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