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

[Corinna Vinschen]

On Apr  3 13:18, Igor Peshansky wrote:
> 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...

No, I meant that mail which isn't using a wrong reply-to.   However,
this stuff is not actually overly important for cygwin-apps, so let's
stay in cygwin-developers.

> > On Apr  3 11:16, Igor Peshansky wrote:
> > > On Thu, 3 Apr 2008, Corinna Vinschen wrote:
> > 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).

Yes, that's possible.  Every form of misconfiguration is possible.  But
that's also the case for the registry based mount points.  The /bin dir
is in / or you might get funny problems.

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

The notion SCM has of %PATH% is taken from the system %PATH% setting.
Show me where you set a service specific %PATH%.  The fact that
cygrunsrv starts without having the cygwin bin dir in the system %PATH%
is a result of cygrunsrv and cygwin1.dll being in the same directory.
If you have a $PATH setting in HKLM/.../service/Parameters/Environment,
then that's set by cygrunsrv and will only help the started service
application, not cygrunsrv itself.

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

I understand your point, but that's nothing which can't be solved
by giving every user a unique DISPLAY id, is it?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat