[HEADSUP] Let's start a Cygwin 1.7 release area
Thu Apr 3 15:16:00 GMT 2008
On Thu, 3 Apr 2008, Corinna Vinschen wrote:
> > >>> 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.
> > 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,
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.
> 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.
> > >Or simply
> > >
> > > root / ntfs binary 0 0
> > >
> > >and stick to /usr/bin and /usr/lib as they are today.
> > I think something like an automount is needed since it would be nice
> > to eventually generalize the cygdrive stuff and we don't want to
> > explicitly mount a: - z: So, maybe we could consider a linux-like
> > solution to accomplish this although I really don't like automount.
> I'm not sure I understand this, that's why I was puzzled above.
> Do you think that / should be free as today:
> C:\arbitrary\useless\new\path / ntfs binary 0 0
> or do you think an automatic approach as the above
> root / ntfs binary 0 0
> is the way to go? As for cygdrives, isn't the
> cygdrive /mnt auto binary 0 0
> already along the lines of an automount?!?
It is, IMHO.
> > >I have the vague feeling it would be sufficient to install only a
> > >/etc/fstab, even in "just me" mode, though. The fstab.$SID file is
> > >only necessary in multi-user installations, IMHO.
> > Why do we need a fstab.$SID and linux doesn't need this?
> Let me think...
> 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.
That, and also to allow completely disjoint Cygwin installations for
different users (where the mount table would otherwise be shared). But
this effect can also be accomplished with /etc/fstab (one per
> 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,
makes the default startup scripts insufficient to allow multiple users to
run Cygwin/X sessions simultaneously, unless that shared location is
overridden in a per-user manner (e.g., through user mounts). So, until we
figure out how to solve that issue, user mounts are actually userful.
|\ _,,,---,,_ email@example.com | firstname.lastname@example.org
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
More information about the Cygwin-apps