Setup for 1.7 must still handle 9x?

Setup for 1.7 must still handle 9x?

[Corinna Vinschen]

And the next question.

I have hacked up a version of setup which handles most of the stuff
necessary to install Cygwin 1.7 now.  However, it contains changes which
are hard to implemented transparently on 9x.  For instance, all local
file access is now using wide char functions which are usually not
available on 9x.  The mount table in the registry is not written anymore,
rather only the {HKLM,HKCU}\Software\Cygwin\setup\rootdir value.

Having only one version of setup which supports the old 1.5 install as
well as the new 1.7 install is extremly tricky, IMHO.

Is it worth it at all?  Isn't it sufficient to keep the 1.5 installer
on the branch and use it for 9x installations in future only?


Corinna

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

Re: Setup for 1.7 must still handle 9x?

[Corinna Vinschen]

On Aug 12 17:35, Corinna Vinschen wrote:
> And the next question.
> 
> I have hacked up a version of setup which handles most of the stuff
> necessary to install Cygwin 1.7 now.  However, it contains changes which
> are hard to implemented transparently on 9x.  For instance, all local
> file access is now using wide char functions which are usually not
> available on 9x.  The mount table in the registry is not written anymore,
> rather only the {HKLM,HKCU}\Software\Cygwin\setup\rootdir value.
> 
> Having only one version of setup which supports the old 1.5 install as
> well as the new 1.7 install is extremly tricky, IMHO.
> 
> Is it worth it at all?  Isn't it sufficient to keep the 1.5 installer
> on the branch and use it for 9x installations in future only?

Never mind.  Baring any dumb mistakes, it's apparently not *that*
complicated.


Corinna

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

Re: Setup for 1.7 must still handle 9x?

[Christopher Faylor]

On Tue, Aug 12, 2008 at 08:02:15PM +0200, Corinna Vinschen wrote:
>On Aug 12 17:35, Corinna Vinschen wrote:
>>Is it worth it at all?  Isn't it sufficient to keep the 1.5 installer
>>on the branch and use it for 9x installations in future only?
>
>Never mind.  Baring any dumb mistakes, it's apparently not *that*
>complicated.

But, FWIW, I would be fine with keeping 1.5 support on a branch.

cgf

Re: Setup for 1.7 must still handle 9x?

[Corinna Vinschen]

On Aug 12 16:25, Christopher Faylor wrote:
> On Tue, Aug 12, 2008 at 08:02:15PM +0200, Corinna Vinschen wrote:
> >On Aug 12 17:35, Corinna Vinschen wrote:
> >>Is it worth it at all?  Isn't it sufficient to keep the 1.5 installer
> >>on the branch and use it for 9x installations in future only?
> >
> >Never mind.  Baring any dumb mistakes, it's apparently not *that*
> >complicated.
> 
> But, FWIW, I would be fine with keeping 1.5 support on a branch.

Too late :)

I just applied my patch.  This version now uses setup-2.ini on NT and
setup.ini on 9x.  I tested it on XP and 98.

New features:

- Installs 1.7 on NT and 1.5.x on 9x.

- Uses wide char functions, long path names and the Cygwin UNICODE
  transformation of special DOS characters on NT.

- Reads package DB the first time *after* the user pressed the "Next"
  button in the root dir dialog, so that setup doesn't use the package
  DB from a former installation by accident if the user chooses to
  install into a new directory.

- Tries to fetch the root dir from {HKLM,HKCU}/Software/Cygwin/setup/rootdir
  Stores it there at installation time.

- Does not write registry mount points on NT.

- Dynamically changes the layout of the root dir dialog so that there's
  no user choice for text/binmode.

It works for me(TM), so I don't know what I screwed up.  But at least
we have finally a version of setup which can be used by all package
maintainers.

If nobody beats me to it, I'll upload this version as setup-1.7.exe to
http://cygwin.com tomorrow.


Peace,
Corinna

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

Re: Setup for 1.7 must still handle 9x?

[Ralph Hempel]

Corinna Vinschen wrote:

> It works for me(TM), so I don't know what I screwed up.  But at least
> we have finally a version of setup which can be used by all package
> maintainers.
> 
> If nobody beats me to it, I'll upload this version as setup-1.7.exe to
> http://cygwin.com tomorrow.

Glad to see you've been able to maintain compatibility with Win95 :-)

Not to belabour a point, but did Dave Korn's work on the command
line package spec ability make it into this version?

Cheers, Ralph

Re: Setup for 1.7 must still handle 9x?

[Corinna Vinschen]

On Aug 12 19:09, Ralph Hempel wrote:
> Corinna Vinschen wrote:
>
>> It works for me(TM), so I don't know what I screwed up.  But at least
>> we have finally a version of setup which can be used by all package
>> maintainers.
>> If nobody beats me to it, I'll upload this version as setup-1.7.exe to
>> http://cygwin.com tomorrow.
>
> Glad to see you've been able to maintain compatibility with Win95 :-)
>
> Not to belabour a point, but did Dave Korn's work on the command
> line package spec ability make it into this version?

Yes, from the ChangeLog it seems so.


Corinna

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

New Setup for Cygwin 1.7 on cygwin.com

[Corinna Vinschen]

Hi,

I just uploaded a new setup-1.7.exe to install Cygwin 1.7.

You can find it here:  http://cygwin.com/setup-1.7.exe 

The version number is 2.605.
The SHA1 checksum is 42ba9cfb36f21c55d6cbfff8e48b20202f0d85c1

Features:

- Installs 1.7 on NT and 1.5.x on 9x.

As far as NT is affected:

- Uses long path names and the Cygwin UNICODE transformation of special
  DOS characters.  This should allow to install files with special DOS
  chars (foo:bar, a<b), as well as files with names consisting of DOS
  device names (nul.exe, aux.c).

- Setup will still look for an old install by searching the 1.5.x
  registry mount points.  If you don't change to another dir in the
  "Choose Installation Directory" dialog, it will perform an upgrade
  rather than a fresh parallel install.  So, please change the root
  directory to something like, say, C:\cygwin-1.7

- Reads package DB the first time *after* the user pressed the "Next"
  button in the "Choose Installation Directory" dialog, so that setup
  doesn't use the package DB from a former installation by accident if
  the user chooses to install into a new directory.
  
  This only works once! 
  
  If you press the "Next" button in the "Choose Installation Directory"
  dialog before you changed the root directory, then press the "Back"
  button, it's too late.  In that case, press "Cancel" and restart
  Setup-1.7.
  
  I couldn't figure out how to drop the entire package DB in memory so
  that it can be re-read when the directory gets changed by the user.
  Can somebody help coding this?

- Does not write registry mount points anymore.

- Dynamically changes the layout of the "Choose Installation Directory"
  dialog so that there's no user choice for text/binmode.

Other changes:

- Silently skip empty tar packages of the 46 byte type (for instance
  gcc-3.4.4-3).

- New command-line option which was already present in Dave's test
  release 2.602:
  
  -P --packages                          Specify packages to install

Perhaps I screwed something up with my patches which worked before,
but it worked fine for me, so I don't know.  Please give it a try
and report back.


Have fun,
Corinna




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

Re: New Setup for Cygwin 1.7 on cygwin.com

[Dr. Volker Zell]

>>>>> Corinna Vinschen writes:

    > Hi,
    > I just uploaded a new setup-1.7.exe to install Cygwin 1.7.

I tried a parallel net install on my 1.5 system on XP with only the base
system for 1.7:


$ cd /

vzell@xp /
$ ls -lt
ls: reading directory .: Bad addres                                            <----- What's this ??
total 6
drwxrwxrwt+ 1 vzell Users    0 Aug 15 10:43 tmp
drwxrwxrwx+ 1 vzell None     0 Aug 15 10:43 home
-rwxr-xr-x  1 vzell Users   61 Aug 15 10:42 Cygwin.bat
-rwxr-xr-x  1 vzell Users 7022 Aug 15 10:42 Cygwin.ico
drwxr-xr-x+ 1 vzell Users    0 Aug 15 10:41 etc
drwxr-xr-x+ 1 vzell Users    0 Aug 15 10:41 dev
drwxr-xr-x+ 1 vzell Users    0 Aug 15 10:41 cygdrive
lrwxrwxrwx  1 vzell Users   17 Aug 15 10:41 terminfo ->../share/terminfo      <----- This seems to be wrong
drwxr-xr-x+ 1 vzell Users    0 Aug 15 10:41 var
drwxr-xr-x+ 1 vzell Users    0 Aug 15 10:41 bin
drwxr-xr-x+ 1 vzell Users    0 Aug 15 10:40 lib
drwxr-xr-x+ 1 vzell Users    0 Aug 15 10:39 usr
dr-xr-xr-x  8 vzell None     0 Dec  1  2006 proc

vzell@xp /
$ mount
D:\cygwin-1.7\bin on /usr/bin type ntfs (binary)
D:\cygwin-1.7\lib on /usr/lib type ntfs (binary)
D:\cygwin-1.7 on / type ntfs (binary)
c: on /c type ntfs (binary,user,noumount)
d: on /d type ntfs (binary,user,noumount)
e: on /e type iso9660 (binary,user,noumount)
s: on /s type unknown (binary,user,noumount)

vzell@xp /
$ mount -p
Prefix              Type         Flags
/                   user         binmode
    
Ciao
  Volker

Re: New Setup for Cygwin 1.7 on cygwin.com

[Corinna Vinschen]

On Aug 15 10:53, Dr. Volker Zell wrote:
> >>>>> Corinna Vinschen writes:
> 
>     > Hi,
>     > I just uploaded a new setup-1.7.exe to install Cygwin 1.7.
> 
> I tried a parallel net install on my 1.5 system on XP with only the base
> system for 1.7:
> 
> 
> $ cd /
> 
> vzell@xp /
> $ ls -lt
> ls: reading directory .: Bad addres                                            <----- What's this ??

That's a result of using / as cygdrive prefix.  I look into that.

> total 6
> drwxrwxrwt+ 1 vzell Users    0 Aug 15 10:43 tmp
> drwxrwxrwx+ 1 vzell None     0 Aug 15 10:43 home
> -rwxr-xr-x  1 vzell Users   61 Aug 15 10:42 Cygwin.bat
> -rwxr-xr-x  1 vzell Users 7022 Aug 15 10:42 Cygwin.ico
> drwxr-xr-x+ 1 vzell Users    0 Aug 15 10:41 etc
> drwxr-xr-x+ 1 vzell Users    0 Aug 15 10:41 dev
> drwxr-xr-x+ 1 vzell Users    0 Aug 15 10:41 cygdrive
> lrwxrwxrwx  1 vzell Users   17 Aug 15 10:41 terminfo ->../share/terminfo      <----- This seems to be wrong

Dunno where this is coming from but I assume this is also a result
of using / as cygdrive prefix.


Corinna

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

Re: New Setup for Cygwin 1.7 on cygwin.com

[Corinna Vinschen]

On Aug 15 12:28, Corinna Vinschen wrote:
> On Aug 15 10:53, Dr. Volker Zell wrote:
> > lrwxrwxrwx  1 vzell Users   17 Aug 15 10:41 terminfo ->../share/terminfo      <----- This seems to be wrong
> 
> Dunno where this is coming from but I assume this is also a result
> of using / as cygdrive prefix.

Apparently not.  If you have a look into /var/log/setup.log, you can see
that this is a result of the order in which the postinstall scripts are
running.  The problem is that the script 000-cygwin-post-install.sh from
the base-cygwin package is not run as the first script, so that we don't
have a fstab file (and no usr/lib mount point) when the terminfo
postinstall script runs.

Here's another problem:  The bash postinstall script runs prior to
the 000-cygwin-post-install.sh script as well and fails exit code 127,
because it calls /usr/bin/install-info.  Since the /usr/bin mount point
is created in 000-cygwin-post-install.sh, it doesn't exist so far and
the call fails.  That shouldn't hurt since update-info-dir.sh runs
fine (it calls install-info without full path), but it shows the general
problem.

Along these lines, the coreutils postinstall script runs before the
bash script as well even though its setup.hint file requires bash.
Huh?

So, how can we make sure that the 000-cygwin-post-install.sh script
from the base-cygwin package runs as the first script?  Does it work
to make bash depend on base-cygwin?


Corinna

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

Re: New Setup for Cygwin 1.7 on cygwin.com

[Corinna Vinschen]

On Aug 15 13:21, Corinna Vinschen wrote:
> > On Aug 15 10:53, Dr. Volker Zell wrote:
> > > lrwxrwxrwx  1 vzell Users   17 Aug 15 10:41 terminfo ->../share/terminfo      <----- This seems to be wrong
> 
> Apparently not.  If you have a look into /var/log/setup.log, you can see
> that this is a result of the order in which the postinstall scripts are
> running.  The problem is that the script 000-cygwin-post-install.sh from
> the base-cygwin package is not run as the first script, so that we don't
> have a fstab file (and no usr/lib mount point) when the terminfo
> postinstall script runs.
> 
> Here's another problem:  The bash postinstall script runs prior to
> the 000-cygwin-post-install.sh script as well and fails exit code 127,
> because it calls /usr/bin/install-info.  Since the /usr/bin mount point
> is created in 000-cygwin-post-install.sh, it doesn't exist so far and
> the call fails.  That shouldn't hurt since update-info-dir.sh runs
> fine (it calls install-info without full path), but it shows the general
> problem.
> 
> Along these lines, the coreutils postinstall script runs before the
> bash script as well even though its setup.hint file requires bash.
> Huh?
> 
> So, how can we make sure that the 000-cygwin-post-install.sh script
> from the base-cygwin package runs as the first script?  Does it work
> to make bash depend on base-cygwin?

Eric?  Is the latter feasible?  I created the 000-cygwin-post-install.sh
in a way so that it only requires bash itself, not any coreutils tool.


Corinna

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

Re: New Setup for Cygwin 1.7 on cygwin.com

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Corinna Vinschen on 8/15/2008 7:13 AM:
>>
>> So, how can we make sure that the 000-cygwin-post-install.sh script
>> from the base-cygwin package runs as the first script?  Does it work
>> to make bash depend on base-cygwin?
> 
> Eric?  Is the latter feasible?  I created the 000-cygwin-post-install.sh
> in a way so that it only requires bash itself, not any coreutils tool.

I don't know setup.exe well enough to say if that extra dependency will
help, but a) it can't hurt, and b) it's worth a shot.  I've tweaked the
setup.hint in release-2 accordingly.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             ebb9@byu.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkilgb0ACgkQ84KuGfSFAYDwQwCgwd2AidoR4Xb0y028GQwCU1GA
gLkAniehv7cWIphIV67sZmcXk5TJ+Q6K
=p9bq
-----END PGP SIGNATURE-----

Re: New Setup for Cygwin 1.7 on cygwin.com

[Corinna Vinschen]

On Aug 15 07:16, Eric Blake wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> According to Corinna Vinschen on 8/15/2008 7:13 AM:
> >>
> >> So, how can we make sure that the 000-cygwin-post-install.sh script
> >> from the base-cygwin package runs as the first script?  Does it work
> >> to make bash depend on base-cygwin?
> > 
> > Eric?  Is the latter feasible?  I created the 000-cygwin-post-install.sh
> > in a way so that it only requires bash itself, not any coreutils tool.
> 
> I don't know setup.exe well enough to say if that extra dependency will
> help, but a) it can't hurt, and b) it's worth a shot.  I've tweaked the
> setup.hint in release-2 accordingly.

Cool, thanks!  I'll try a fresh reinstall soon.

What I still don't get is that, in my local install, the update-info-dir,
coreutils, and terminfo postinstall scripts ran before the bash postinstall
script, even though all of them list bash as requirement.  Any idea?


Corinna

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

Re: New Setup for Cygwin 1.7 on cygwin.com

[Corinna Vinschen]

On Aug 15 15:28, Corinna Vinschen wrote:
> On Aug 15 07:16, Eric Blake wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > According to Corinna Vinschen on 8/15/2008 7:13 AM:
> > >>
> > >> So, how can we make sure that the 000-cygwin-post-install.sh script
> > >> from the base-cygwin package runs as the first script?  Does it work
> > >> to make bash depend on base-cygwin?
> > > 
> > > Eric?  Is the latter feasible?  I created the 000-cygwin-post-install.sh
> > > in a way so that it only requires bash itself, not any coreutils tool.
> > 
> > I don't know setup.exe well enough to say if that extra dependency will
> > help, but a) it can't hurt, and b) it's worth a shot.  I've tweaked the
> > setup.hint in release-2 accordingly.
> 
> Cool, thanks!  I'll try a fresh reinstall soon.

Hang on.  Of course base-cygwin requires bash *and* coreutils since it
calls cat, mkdir and rm.

The setup.hint file of base-cygwin has a 

  requires: bash coreutils

line.  That's a recursion.  Won't the order in which the postinstall
files are running be pure coincidence?

Shouldn't the requires line be removed in base-cygwin to get this
working reliably?!?  Geeh, I'm getting headaches.


Corinna

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

Re: New Setup for Cygwin 1.7 on cygwin.com

[Brian Dessent]

Corinna Vinschen wrote:

> What I still don't get is that, in my local install, the update-info-dir,
> coreutils, and terminfo postinstall scripts ran before the bash postinstall
> script, even though all of them list bash as requirement.  Any idea?

It's a circular dependency -- _update-info-dir and bash both list each
other as requirements.  In such a situation with loops it's impossible
to give a topological ordering that satisfies both constraints, so it
comes down to chance (or rather the order that things are evaluated) as
to which goes first.  It looks like _update-info-dir happens to get to
the top.

Brian

Re: New Setup for Cygwin 1.7 on cygwin.com

[Corinna Vinschen]

On Aug 15 06:45, Brian Dessent wrote:
> Corinna Vinschen wrote:
> 
> > What I still don't get is that, in my local install, the update-info-dir,
> > coreutils, and terminfo postinstall scripts ran before the bash postinstall
> > script, even though all of them list bash as requirement.  Any idea?
> 
> It's a circular dependency -- _update-info-dir and bash both list each
> other as requirements.  In such a situation with loops it's impossible
> to give a topological ordering that satisfies both constraints, so it
> comes down to chance (or rather the order that things are evaluated) as
> to which goes first.  It looks like _update-info-dir happens to get to
> the top.

I don't see _update-info-dir in the bash requires.

However, when looking through the dependencies, I see more problems.

  cygwin requires base-passwd

  base-passwd requires bash

  bash requires cygwin

We really need a strategy to fix the dependencies so that postinstall
scripts of crucial packages run first.  And base-cygwin should run
before every other package.

Any chance we can discuss this on IRC (freenode: #cygwin-developers)?


Corinna

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

Re: New Setup for Cygwin 1.7 on cygwin.com

[Brian Dessent]

Corinna Vinschen wrote:

> I don't see _update-info-dir in the bash requires.

Are you looking at the setup.hint or the generated setup.ini?  IIRC it's
added by upset automatically if it detects the package has .info files.

> However, when looking through the dependencies, I see more problems.
> 
>   cygwin requires base-passwd
> 
>   base-passwd requires bash
> 
>   bash requires cygwin
> 
> We really need a strategy to fix the dependencies so that postinstall
> scripts of crucial packages run first.  And base-cygwin should run
> before every other package.

Didn't Eric upload a new bash package that is postinstal-less?  Or is
there an older one in release-2/ that shadows the newer one in release/?

To make base-cygwin run first, it should suffice to list it as a
dependency of e.g. bash or cygwin and to have it not depend on
anything.  Rationale: its dependencies (bash and coreutils) are in Base
and should be installed regardless so it shouldn't hurt to not list
them.  All listing them does is cause loops.

Brian

Re: New Setup for Cygwin 1.7 on cygwin.com

[Corinna Vinschen]

On Aug 15 07:15, Brian Dessent wrote:
> Corinna Vinschen wrote:
> 
> > I don't see _update-info-dir in the bash requires.
> 
> Are you looking at the setup.hint or the generated setup.ini?  IIRC it's
> added by upset automatically if it detects the package has .info files.
> 
> > However, when looking through the dependencies, I see more problems.
> > 
> >   cygwin requires base-passwd
> > 
> >   base-passwd requires bash
> > 
> >   bash requires cygwin
> > 
> > We really need a strategy to fix the dependencies so that postinstall
> > scripts of crucial packages run first.  And base-cygwin should run
> > before every other package.
> 
> Didn't Eric upload a new bash package that is postinstal-less?  Or is
> there an older one in release-2/ that shadows the newer one in release/?
> 
> To make base-cygwin run first, it should suffice to list it as a
> dependency of e.g. bash or cygwin and to have it not depend on
> anything.  Rationale: its dependencies (bash and coreutils) are in Base
> and should be installed regardless so it shouldn't hurt to not list
> them.  All listing them does is cause loops.

Ok, I changed the requires in release-2 as follows:

  cygwin      requries: base-passwd base-cygwin
  base-passwd requires: base-cygwin
  base-cygwin requires: nothing

I left base-files out of the picture for now because it also depends on
findutils and sed.  I hope that won't hurt.


Corinna

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

RE: New Setup for Cygwin 1.7 on cygwin.com

[Dave Korn]

[-- Attachment #1: Type: text/plain, Size: 1233 bytes --]

Brian Dessent wrote on 15 August 2008 14:46:

> Corinna Vinschen wrote:
> 
>> What I still don't get is that, in my local install, the update-info-dir,
>> coreutils, and terminfo postinstall scripts ran before the bash
>> postinstall script, even though all of them list bash as requirement. 
>> Any idea? 
> 
> It's a circular dependency -- _update-info-dir and bash both list each
> other as requirements.  

  And not the only one; see my graph for an illustration.  (That's a
manually-extracted subgraph of the whole dependency mesh, but 'complete' in
the sense that I've only omitted incoming dependencies).

> In such a situation with loops it's impossible
> to give a topological ordering that satisfies both constraints, so it
> comes down to chance (or rather the order that things are evaluated) as
> to which goes first.  It looks like _update-info-dir happens to get to
> the top.

  I think that the recent change to the depth that setup follows
dependencies may well have changed the number of times it cycles round any
given loop and therefore changed which dependency it ends up thinking is the
lowest when it hits that limit and stops cycling.


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

[-- Attachment #2: setup3.dot.png --]
[-- Type: image/png, Size: 28852 bytes --]

Re: New Setup for Cygwin 1.7 on cygwin.com

[Corinna Vinschen]

On Aug 15 15:03, Dave Korn wrote:
> Brian Dessent wrote on 15 August 2008 14:46:
> 
> > Corinna Vinschen wrote:
> > 
> >> What I still don't get is that, in my local install, the update-info-dir,
> >> coreutils, and terminfo postinstall scripts ran before the bash
> >> postinstall script, even though all of them list bash as requirement. 
> >> Any idea? 
> > 
> > It's a circular dependency -- _update-info-dir and bash both list each
> > other as requirements.  
> 
>   And not the only one; see my graph for an illustration.  (That's a
> manually-extracted subgraph of the whole dependency mesh, but 'complete' in
> the sense that I've only omitted incoming dependencies).

Yuk!  Would it help if the base-* packages have no dependencies at all
and cygwin itself depends on the base-* packages?  How would that change
your graph (and, can you create it for the release-2 dir, please?)


Corinna

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

RE: New Setup for Cygwin 1.7 on cygwin.com

[Dave Korn]

Corinna Vinschen wrote on 15 August 2008 15:12:

> Yuk!  Would it help if the base-* packages have no dependencies at all
> and cygwin itself depends on the base-* packages?  How would that change
> your graph (and, can you create it for the release-2 dir, please?)

  I shouldn't even be taking five minutes out to write emails right now, so
apologies in advance, I'm going back off the air and will talk to everyone
at the weekend.  But yes, NP.

  TGIF!

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

RE: New Setup for Cygwin 1.7 on cygwin.com

[Dave Korn]

[-- Attachment #1: Type: text/plain, Size: 1328 bytes --]

Corinna Vinschen wrote on 15 August 2008 15:12:

> Yuk!  Would it help if the base-* packages have no dependencies at all
> and cygwin itself depends on the base-* packages?  How would that change
> your graph (and, can you create it for the release-2 dir, please?)

  Still not got a lot of time right now, but here's the script that makes
dotty output.  (Don't try sending .dot files to the lists, BTW - the spam
filter thinks they're MS Word template files!  Fortunately the extension
isn't meaningful to graphviz anyway.)

  You'll find it generates a HUUUUuuuuuge graph that's very hard to manage -
too big for the jpg renderer, as a png it crashed my viewer, and by the time
you've blown enough of it up to read the labels you can hardly see what's
what.  I manually extracted a subgraph by copying bits of text from the
script-generated file into a fresh file.  Each package comes as a separate
hunk with its dependencies listed, so I took a few of the low-level packages
(such as cygwin and base-files), then iteratively copied the hunks for all
the dependencies they listed, until there were no unsatisfied dependencies
left in the new graph.  It didn't take long to do, so I didn't bother
scripting it, but it could easily be added as a feature.


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

[-- Attachment #2: setupini2dot.pl --]
[-- Type: application/octet-stream, Size: 651 bytes --]

#!perl

use strict;

my $packagename;
my $requires;

print "digraph setup_ini {\n";

while (<>)
{
  if (/^@/)
  {
    # Get current line
    $packagename=$_;
    # Strip leading @ and space
    $packagename=~s/^@ //;
    # Remove EOL for concatenation later
    chomp($packagename);
  }

  if (/^requires: /)
  {
    $requires=$_;
    # Strip non-package name header
    $requires=~ s/^requires: //;
    # and EOL
    chomp($requires);
    # Put quotes around each name
    $requires=~ s/([^ ]+)/"$packagename" -> "\1" ;\n/g;
    print $requires . "\n";
  }
}
continue
{
  close ARGV if eof;
}

print "}\n";

Re: New Setup for Cygwin 1.7 on cygwin.com

[Corinna Vinschen]

On Aug 16 13:25, Dave Korn wrote:
> Corinna Vinschen wrote on 15 August 2008 15:12:
> 
> > Yuk!  Would it help if the base-* packages have no dependencies at all
> > and cygwin itself depends on the base-* packages?  How would that change
> > your graph (and, can you create it for the release-2 dir, please?)
> 
>   Still not got a lot of time right now, but here's the script that makes
> dotty output.  (Don't try sending .dot files to the lists, BTW - the spam
> filter thinks they're MS Word template files!  Fortunately the extension
> isn't meaningful to graphviz anyway.)

Here's what setup tells us right now about the dependency order when
performing a pure Base install from scratch:

warning: LOG: 1 Dependency order of packages: libintl3 texinfo
_update-info-dir gawk tzcode libiconv2 coreutils terminfo libncurses8
libreadline6 bash base-cygwin base-passwd cygwin libintl8 alternatives
ash findutils sed base-files libbz2_1 bzip2 libpopt0 cygutils groff gzip
termcap libpcre0 less man cygwin-doc editrights grep ipc-utils login
rebase run tar which
                                
How in the world can cygwin and the base-cygwin/base-passwd packages be
so far from the root in the dependency tree?  Why is libintl3 in the list
but libintl8 isn't?  Is the dependecy mechanism really reliable?

Last but not least, how do we disentangle this mess?


Corinna

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

Re: New Setup for Cygwin 1.7 on cygwin.com

[Brian Dessent]

Corinna Vinschen wrote:

> How in the world can cygwin and the base-cygwin/base-passwd packages be
> so far from the root in the dependency tree?  Why is libintl3 in the list
> but libintl8 isn't?  Is the dependecy mechanism really reliable?

Essentially, because the Cygwin package depends on _update_info_dir. 
That brings in a dependency on texinfo, which brings in libiconv2,
libintl3, libncurses8.  libncurses8 brings in terminfo which brings in
bash and coreutils which brings in tzcode which brings in gawk.  And
that's pretty much the list of things that run before base-cygwin:

libintl3 texinfo _update-info-dir gawk tzcode libiconv2 coreutils
terminfo libncurses8 libreadline6 bash

You have to remember that the topological ordering code throws out an
edge when it detects a loop.  So if it's looking at the dependencies of
FOO to figure out what to run before FOO's postinstall and it finds a
package that depends on FOO it's going to just silently discard that
edge because there's nothing meaningful it can do with it.  If it
didn't, it would just recurse forever on the loops.  So it doesn't
matter that practically all of the above also depend on 'cygwin', which
would logically mean 'cygwin' should come before them.  But that logic
just leads to infinite recursion; setup has to consider only one edge in
the loop and it chooses whichever one it saw first.

Can we special-case upset not to add _update-info-dir to the Cygwin
package?

Brian

Re: New Setup for Cygwin 1.7 on cygwin.com

[Christopher Faylor]

On Tue, Aug 19, 2008 at 06:48:44PM -0700, Brian Dessent wrote:
>Can we special-case upset not to add _update-info-dir to the Cygwin
>package?

I'm not a big fan of special casing and in this case I don't have to.
I just added a "noautodep: _update_info_dir" to cygwin's setup.hint.

But we'll still get a dependency loop with base-passwd.  I have removed
that dependency in release.  It looks like this isn't needed in
release-2.

cgf

Re: New Setup for Cygwin 1.7 on cygwin.com

[Corinna Vinschen]

On Aug 19 22:46, Christopher Faylor wrote:
> On Tue, Aug 19, 2008 at 06:48:44PM -0700, Brian Dessent wrote:
> >Can we special-case upset not to add _update-info-dir to the Cygwin
> >package?
> 
> I'm not a big fan of special casing and in this case I don't have to.
> I just added a "noautodep: _update_info_dir" to cygwin's setup.hint.

Cool.  I'm curious how this changes the dependency order.

> But we'll still get a dependency loop with base-passwd.  I have removed
> that dependency in release.  It looks like this isn't needed in
> release-2.

I removed all dependencies from release-2/base-passwd except for
base-cygwin a couple of days ago.  Hopefully we get to the point
where the base packages' postinstalls run first.


Corinna

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

Re: New Setup for Cygwin 1.7 on cygwin.com

[Christopher Faylor]

On Wed, Aug 20, 2008 at 09:57:51AM +0200, Corinna Vinschen wrote:
>On Aug 19 22:46, Christopher Faylor wrote:
>> On Tue, Aug 19, 2008 at 06:48:44PM -0700, Brian Dessent wrote:
>> >Can we special-case upset not to add _update-info-dir to the Cygwin
>> >package?
>> 
>> I'm not a big fan of special casing and in this case I don't have to.
>> I just added a "noautodep: _update_info_dir" to cygwin's setup.hint.
>
>Cool.  I'm curious how this changes the dependency order.
>
>> But we'll still get a dependency loop with base-passwd.  I have removed
>> that dependency in release.  It looks like this isn't needed in
>> release-2.
>
>I removed all dependencies from release-2/base-passwd except for
>base-cygwin a couple of days ago.  Hopefully we get to the point
>where the base packages' postinstalls run first.

Keeping a base-dependency in cygwin would make setup want to run base-*
before cygwin, though.  Cygwin doesn't *really* depend on these packages
(it doesn't need them to run) so I don't think they should be a
dependency.

cgf

Re: New Setup for Cygwin 1.7 on cygwin.com

[Corinna Vinschen]

On Aug 20 10:39, Christopher Faylor wrote:
> On Wed, Aug 20, 2008 at 09:57:51AM +0200, Corinna Vinschen wrote:
> >On Aug 19 22:46, Christopher Faylor wrote:
> >> On Tue, Aug 19, 2008 at 06:48:44PM -0700, Brian Dessent wrote:
> >> >Can we special-case upset not to add _update-info-dir to the Cygwin
> >> >package?
> >> 
> >> I'm not a big fan of special casing and in this case I don't have to.
> >> I just added a "noautodep: _update_info_dir" to cygwin's setup.hint.
> >
> >Cool.  I'm curious how this changes the dependency order.
> >
> >> But we'll still get a dependency loop with base-passwd.  I have removed
> >> that dependency in release.  It looks like this isn't needed in
> >> release-2.
> >
> >I removed all dependencies from release-2/base-passwd except for
> >base-cygwin a couple of days ago.  Hopefully we get to the point
> >where the base packages' postinstalls run first.
> 
> Keeping a base-dependency in cygwin would make setup want to run base-*
> before cygwin, though.  Cygwin doesn't *really* depend on these packages
> (it doesn't need them to run) so I don't think they should be a
> dependency.

That's the whole idea.  Cygwin itself has no postinstall scripts, but
the base-* scripts should run first.  That's why the dependencies make
sense.  What else packages should depend on the base-* packages to
accomplish this?


Corinna

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

Re: New Setup for Cygwin 1.7 on cygwin.com

[Christopher Faylor]

On Wed, Aug 20, 2008 at 04:46:30PM +0200, Corinna Vinschen wrote:
>On Aug 20 10:39, Christopher Faylor wrote:
>> On Wed, Aug 20, 2008 at 09:57:51AM +0200, Corinna Vinschen wrote:
>> >On Aug 19 22:46, Christopher Faylor wrote:
>> >> On Tue, Aug 19, 2008 at 06:48:44PM -0700, Brian Dessent wrote:
>> >> >Can we special-case upset not to add _update-info-dir to the Cygwin
>> >> >package?
>> >> 
>> >> I'm not a big fan of special casing and in this case I don't have to.
>> >> I just added a "noautodep: _update_info_dir" to cygwin's setup.hint.
>> >
>> >Cool.  I'm curious how this changes the dependency order.
>> >
>> >> But we'll still get a dependency loop with base-passwd.  I have removed
>> >> that dependency in release.  It looks like this isn't needed in
>> >> release-2.
>> >
>> >I removed all dependencies from release-2/base-passwd except for
>> >base-cygwin a couple of days ago.  Hopefully we get to the point
>> >where the base packages' postinstalls run first.
>> 
>> Keeping a base-dependency in cygwin would make setup want to run base-*
>> before cygwin, though.  Cygwin doesn't *really* depend on these packages
>> (it doesn't need them to run) so I don't think they should be a
>> dependency.
>
>That's the whole idea.  Cygwin itself has no postinstall scripts, but
>the base-* scripts should run first.  That's why the dependencies make
>sense.  What else packages should depend on the base-* packages to
>accomplish this?

I thought the whole point was to install cygwin first.  How can you run base
packages first in a new install when there is no cygwin1.dll?

cgf

Re: New Setup for Cygwin 1.7 on cygwin.com

[Corinna Vinschen]

On Aug 20 11:17, Christopher Faylor wrote:
> On Wed, Aug 20, 2008 at 04:46:30PM +0200, Corinna Vinschen wrote:
> >On Aug 20 10:39, Christopher Faylor wrote:
> >> On Wed, Aug 20, 2008 at 09:57:51AM +0200, Corinna Vinschen wrote:
> >> >I removed all dependencies from release-2/base-passwd except for
> >> >base-cygwin a couple of days ago.  Hopefully we get to the point
> >> >where the base packages' postinstalls run first.
> >> 
> >> Keeping a base-dependency in cygwin would make setup want to run base-*
> >> before cygwin, though.  Cygwin doesn't *really* depend on these packages
> >> (it doesn't need them to run) so I don't think they should be a
> >> dependency.
> >
> >That's the whole idea.  Cygwin itself has no postinstall scripts, but
> >the base-* scripts should run first.  That's why the dependencies make
> >sense.  What else packages should depend on the base-* packages to
> >accomplish this?
> 
> I thought the whole point was to install cygwin first.  How can you run base
> packages first in a new install when there is no cygwin1.dll?

The installation order doesn't matter.  Only the order in which scripts
run matters.  And I don't see another way how to make sure that the
base-* scripts always run first.


Corinna

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

Re: New Setup for Cygwin 1.7 on cygwin.com

[Christopher Faylor]

On Wed, Aug 20, 2008 at 05:25:46PM +0200, Corinna Vinschen wrote:
>On Aug 20 11:17, Christopher Faylor wrote:
>> On Wed, Aug 20, 2008 at 04:46:30PM +0200, Corinna Vinschen wrote:
>> >On Aug 20 10:39, Christopher Faylor wrote:
>> >> On Wed, Aug 20, 2008 at 09:57:51AM +0200, Corinna Vinschen wrote:
>> >> >I removed all dependencies from release-2/base-passwd except for
>> >> >base-cygwin a couple of days ago.  Hopefully we get to the point
>> >> >where the base packages' postinstalls run first.
>> >> 
>> >> Keeping a base-dependency in cygwin would make setup want to run base-*
>> >> before cygwin, though.  Cygwin doesn't *really* depend on these packages
>> >> (it doesn't need them to run) so I don't think they should be a
>> >> dependency.
>> >
>> >That's the whole idea.  Cygwin itself has no postinstall scripts, but
>> >the base-* scripts should run first.  That's why the dependencies make
>> >sense.  What else packages should depend on the base-* packages to
>> >accomplish this?
>> 
>> I thought the whole point was to install cygwin first.  How can you run base
>> packages first in a new install when there is no cygwin1.dll?
>
>The installation order doesn't matter.  Only the order in which scripts
>run matters.  And I don't see another way how to make sure that the
>base-* scripts always run first.

AFAIK, the requires line controls the way that the packages themselves
are installed.  I think it is important that the newest version of
cygwin should be installed first regardless of subsequent install script
processing.  Maybe we need a dummy package to ensure the subsequent ordering
of post-install or we need a postinstall-requires?

cgf

Re: New Setup for Cygwin 1.7 on cygwin.com

[Charles Wilson]

Corinna Vinschen wrote:

>> I thought the whole point was to install cygwin first.  How can you run base
>> packages first in a new install when there is no cygwin1.dll?
> 
> The installation order doesn't matter.  Only the order in which scripts
> run matters.  And I don't see another way how to make sure that the
> base-* scripts always run first.

Well, what we have is a dependency-group.  You want cygwin, base-*
installed at the same time. Then you want the base-* postinstall scripts
to run.

Maybe a meta-package?

cygwin : no dependencies
base-* : depends on cygwin
cygwin-meta : depends on cygwin, base-*

everything else, that currently depends on cygwin, depends instead on
cygwin-meta.

====> revision for less ripple:

what we now call the 'cygwin' package gets renamed to 'cygwin-core'
base-*: depend on cygwin-core
the new 'cygwin' package is now a meta-package with dependencies on
cygwin-core and base-*.

everything else continues to depend on cygwin, as before.

The drawback to this plan is:
    cygcheck -cd cygwin
will report the version number of the meta-package, which will probably
be 1.0, and will hardly ever change.




This doesn't solve the loop back to cygwin/bash with base-*:

   base-passwd, setup.hint:
      requries: cygwin bash
      NOTE: uses coreutils (cp, rm, chmod) and sed, but
            does not include them in its requires:.

   base-files, setup.hint
      requries:  cygwin bash findutils sed
      NOTE: uses coreutils, diffutils (uname, [, ln,
                 /bin/echo, /bin/touch,
                 /bin/cp, /bin/cmp, /bin/rm ) but does
                 not include them in its requires:.
      FWIW, does NOT seem to use sed or findutils!

   bash: requires cygwin libintl8 libreadline6
   libintl8: requires cygwin libiconv2
   libreadline6: requires cygwin libncurses8
   libiconv2: requries cygwin
   libncurses8: requires cygwin terminfo
   terminfo: requires bash coreutils
      NOTE: the only reason this pulls in coreutils is because the
      postinstall script does this:
	(cd ${libdir};
	  rm -f terminfo  ; ln -fs ../share/terminfo terminfo ;
	)
      which (a) I need to change to make an absolute link, instead
      of a relative one, and (b) is it really necessary?  Must
      we have a /usr/lib/terminfo/ path?

   <--- HERE --->

   coreutils: requires bash crypt cygwin libiconv2 libintl8 tzcode
   crypt: cygwin
   tzcode: cygwin bash gawk
   gawk: bash cygwin libintl8

   findutils: requires: bash coreutils cygwin libintl8
   sed: requires: bash cygwin libintl3 libiconv2
   libintl3: requires: cygwin libiconv2

   diffutils: requires: bash cygwin libintl2 libiconv2
   libintl2: requires: cygwin libiconv2

But I think it would solve the script execution order issue.  Also, if we
  (a) removed terminfo's postinstall script and coreutils dependency
  (b) removed the useless findutils and sed dependnecy of base-files
then the dependency chain of (base-* + cygwin-core == new cygwin meta
package) would stop at HERE.  This scheme would then rely on the Base
category to ensure that coreutils, findutils, diffutils, sed, and all
their dependencies are all properly installed, which should be safe enough.

Better, in the group above HERE, the following are true;
  (a) DLL packages don't typically have postinstall scripts
  (b) terminfo won't have a postinstall script [1]
  (c) leaving only bash, and base-* postinstall
      (1) but since bash dep on cygwin (meta), which would dep on
          cygwin-core (no postinstall), and base-*, but base-*
          dep on bash...
still leaves a cycle.

Hmm...what if we deliberatly drop the bash dependency from base-*,
relying on the Base category to ensure it gets installed? Then, there
are no loops at all (in the cygwin meta group):

  base-passwd --> cygwin-core <-- base-files
             ^         ^          ^
              \        |         /
               \       |        /
                -----cygwin-----
                       ^
                       |
           bash, coreutils, etc...


--
Chuck

[1] alternatively, if we DO need a /usr/lib/terminfo symlink, then we
can keep the postinstall script but deliberately drop the dependency on
coreutils (relying on Base category). Then, we still guarantee base-*
scripts go first, because terminfo would depend on bash

Re: New Setup for Cygwin 1.7 on cygwin.com

[Brian Dessent]

Charles Wilson wrote:

> You want cygwin, base-* installed at the same time.

This sentence doesn't make sense to me.  As if it's possible that some
of these might *not* be installed?  They're all in category Base so
they're all getting selected by setup for install on every run
regardless of anything that the dependencies might have to say on the
matter.  I don't understand why the extra level of complication of
meta-packages or dependency groups is needed; all we need to do is trim
or adjust the dependencies to ensure that base-cygwin's postinstall
sorts to the head of the line.  For these core packages that are in Base
it doesn't really matter that their "requires:" line accurately lists
each thing they need, because they're all getting installed anyway.

Brian

Re: New Setup for Cygwin 1.7 on cygwin.com

[Charles Wilson]

Brian Dessent wrote:
> For these core packages that are in Base
> it doesn't really matter that their "requires:" line accurately lists
> each thing they need, because they're all getting installed anyway.

Then it's easy.

cygwin: requires base-*
base-*: no requires at all [*]

No other changes. The end.

Since everything else (except -doc packages, I guess) depends on cygwin,
you're done. The base-* postinstall scripts will always run first (and,
I assume, the base-files preremove script will always run last).

--
Chuck

[*] Assumes it does not matter which of the three base-* postinstall
script runs first: passwd-grp.sh, base-files-mketc.sh,
base-files-profile.sh.

Re: New Setup for Cygwin 1.7 on cygwin.com

[Corinna Vinschen]

On Aug 20 12:48, Charles Wilson wrote:
> Brian Dessent wrote:
> > For these core packages that are in Base
> > it doesn't really matter that their "requires:" line accurately lists
> > each thing they need, because they're all getting installed anyway.
> 
> Then it's easy.
> 
> cygwin: requires base-*
> base-*: no requires at all [*]
> 
> No other changes. The end.

That's (alomst) exactly as I did it in release-2.  Just additionally

  base-passwd requires: base-cygwin


Corinna

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

Re: New Setup for Cygwin 1.7 on cygwin.com

[Corinna Vinschen]

On Aug 20 19:48, Corinna Vinschen wrote:
> On Aug 20 12:48, Charles Wilson wrote:
> > Brian Dessent wrote:
> > > For these core packages that are in Base
> > > it doesn't really matter that their "requires:" line accurately lists
> > > each thing they need, because they're all getting installed anyway.
> > 
> > Then it's easy.
> > 
> > cygwin: requires base-*
> > base-*: no requires at all [*]
> > 
> > No other changes. The end.
> 
> That's (alomst) exactly as I did it in release-2.  Just additionally
> 
>   base-passwd requires: base-cygwin

All we did the last couple of days seems to have helped only marginally,
if at all.  This morning I ran a 1.7 Base install from scratch, and the
dependency order is still as screwed up as before:

  warning: LOG: 1 Dependency order of packages: libintl3 texinfo
  _update-info-dir gawk tzcode libiconv2 coreutils terminfo libncurses8
  libreadline6 bash base-cygwin base-passwd cygwin libintl8 alternatives
  ash findutils sed base-files libbz2_1 bzip2 libpopt0 cygutils groff
  gzip termcap libpcre0 less man cygwin-doc editrights grep ipc-utils
  login rebase run tar which

I followed through the dependencies using a pencil and a sheet of paper
(sorry Dave ;))  and from what I can tell there are two dependency
loops which break the entire dependency order:

  bash    <-> _update_info_dir
  texinfo <-> _update_info_dir

All other dependencies are looking sound from what I can tell.

So, I would like to propose to remove the "requires: bash texinfo" line
from _update_info_dir's setup.hint file.  It appears that these
requirements break the whole ordering.  Maybe we should simply
replace it with "requires: cygwin" instead.

Chris?


Corinna

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

Re: New Setup for Cygwin 1.7 on cygwin.com

[Charles Wilson]

Corinna Vinschen wrote:

>   bash    <-> _update_info_dir
>   texinfo <-> _update_info_dir
> 
> All other dependencies are looking sound from what I can tell.
> 
> So, I would like to propose to remove the "requires: bash texinfo" line
> from _update_info_dir's setup.hint file.  It appears that these
> requirements break the whole ordering.  Maybe we should simply
> replace it with "requires: cygwin" instead.

Seems ok to me, but we'd have to put texinfo into Base, in that case.
Otherwise it won't get installed automatically, and _update_info_dir
would fail on a Base-only install.

Aside: since setup.hint allows comments (which do not clutter
setup.ini), we should probably annotate setup.hints whose requires: have
been...manipulated...in odd ways.

e.g.
===== _update_info_dir/setup.hint =====
sdesc: "Generate info/dir file automatically"
category: _PostInstallLast
requires: cygwin
# also requires texinfo bash, but
#   a) both are in Base, so we rely on that
#   b) we don't explicitly require them because that introduces
#      a bad dependency loop with regards to postinstall scripts
autodep: usr/(?:share/)?info/.*
incver_ifdep: yes
# verpat: (_update_info)(dir-\d+-\d+)(.*)


--
Chuck

Re: New Setup for Cygwin 1.7 on cygwin.com

[Corinna Vinschen]

On Aug 21 07:08, Charles Wilson wrote:
> Corinna Vinschen wrote:
> 
> >   bash    <-> _update_info_dir
> >   texinfo <-> _update_info_dir
> > 
> > All other dependencies are looking sound from what I can tell.
> > 
> > So, I would like to propose to remove the "requires: bash texinfo" line
> > from _update_info_dir's setup.hint file.  It appears that these
> > requirements break the whole ordering.  Maybe we should simply
> > replace it with "requires: cygwin" instead.
> 
> Seems ok to me, but we'd have to put texinfo into Base, in that case.
> Otherwise it won't get installed automatically, and _update_info_dir
> would fail on a Base-only install.

Good hint.

> Aside: since setup.hint allows comments (which do not clutter
> setup.ini), we should probably annotate setup.hints whose requires: have
> been...manipulated...in odd ways.
> 
> e.g.
> ===== _update_info_dir/setup.hint =====
> sdesc: "Generate info/dir file automatically"
> category: _PostInstallLast
> requires: cygwin
> # also requires texinfo bash, but
> #   a) both are in Base, so we rely on that
> #   b) we don't explicitly require them because that introduces
> #      a bad dependency loop with regards to postinstall scripts
> autodep: usr/(?:share/)?info/.*
> incver_ifdep: yes
> # verpat: (_update_info)(dir-\d+-\d+)(.*)

Yes, that probably makes sense.


Corinna

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

Re: New Setup for Cygwin 1.7 on cygwin.com

[Christopher Faylor]

On Thu, Aug 21, 2008 at 12:10:59PM +0200, Corinna Vinschen wrote:
>On Aug 20 19:48, Corinna Vinschen wrote:
>> On Aug 20 12:48, Charles Wilson wrote:
>> > Brian Dessent wrote:
>> > > For these core packages that are in Base
>> > > it doesn't really matter that their "requires:" line accurately lists
>> > > each thing they need, because they're all getting installed anyway.
>> > 
>> > Then it's easy.
>> > 
>> > cygwin: requires base-*
>> > base-*: no requires at all [*]
>> > 
>> > No other changes. The end.
>> 
>> That's (alomst) exactly as I did it in release-2.  Just additionally
>> 
>>   base-passwd requires: base-cygwin
>
>All we did the last couple of days seems to have helped only marginally,
>if at all.  This morning I ran a 1.7 Base install from scratch, and the
>dependency order is still as screwed up as before:
>
>  warning: LOG: 1 Dependency order of packages: libintl3 texinfo
>  _update-info-dir gawk tzcode libiconv2 coreutils terminfo libncurses8
>  libreadline6 bash base-cygwin base-passwd cygwin libintl8 alternatives
>  ash findutils sed base-files libbz2_1 bzip2 libpopt0 cygutils groff
>  gzip termcap libpcre0 less man cygwin-doc editrights grep ipc-utils
>  login rebase run tar which
>
>I followed through the dependencies using a pencil and a sheet of paper
>(sorry Dave ;))  and from what I can tell there are two dependency
>loops which break the entire dependency order:
>
>  bash    <-> _update_info_dir
>  texinfo <-> _update_info_dir
>
>All other dependencies are looking sound from what I can tell.
>
>So, I would like to propose to remove the "requires: bash texinfo" line
>from _update_info_dir's setup.hint file.  It appears that these
>requirements break the whole ordering.  Maybe we should simply
>replace it with "requires: cygwin" instead.
>
>Chris?

Sorry but I think not having _update-info-dir rely on texinfo is not a
good idea.

Can't we just remove the _update-info-dir dependency from bash and
texinfo?

cgf

Re: New Setup for Cygwin 1.7 on cygwin.com

[Christopher Faylor]

On Thu, Aug 21, 2008 at 11:02:06AM -0400, Christopher Faylor wrote:
>On Thu, Aug 21, 2008 at 12:10:59PM +0200, Corinna Vinschen wrote:
>>On Aug 20 19:48, Corinna Vinschen wrote:
>>> On Aug 20 12:48, Charles Wilson wrote:
>>> > Brian Dessent wrote:
>>> > > For these core packages that are in Base
>>> > > it doesn't really matter that their "requires:" line accurately lists
>>> > > each thing they need, because they're all getting installed anyway.
>>> > 
>>> > Then it's easy.
>>> > 
>>> > cygwin: requires base-*
>>> > base-*: no requires at all [*]
>>> > 
>>> > No other changes. The end.
>>> 
>>> That's (alomst) exactly as I did it in release-2.  Just additionally
>>> 
>>>   base-passwd requires: base-cygwin
>>
>>All we did the last couple of days seems to have helped only marginally,
>>if at all.  This morning I ran a 1.7 Base install from scratch, and the
>>dependency order is still as screwed up as before:
>>
>>  warning: LOG: 1 Dependency order of packages: libintl3 texinfo
>>  _update-info-dir gawk tzcode libiconv2 coreutils terminfo libncurses8
>>  libreadline6 bash base-cygwin base-passwd cygwin libintl8 alternatives
>>  ash findutils sed base-files libbz2_1 bzip2 libpopt0 cygutils groff
>>  gzip termcap libpcre0 less man cygwin-doc editrights grep ipc-utils
>>  login rebase run tar which
>>
>>I followed through the dependencies using a pencil and a sheet of paper
>>(sorry Dave ;))  and from what I can tell there are two dependency
>>loops which break the entire dependency order:
>>
>>  bash    <-> _update_info_dir
>>  texinfo <-> _update_info_dir
>>
>>All other dependencies are looking sound from what I can tell.
>>
>>So, I would like to propose to remove the "requires: bash texinfo" line
>>from _update_info_dir's setup.hint file.  It appears that these
>>requirements break the whole ordering.  Maybe we should simply
>>replace it with "requires: cygwin" instead.
>>
>>Chris?
>
>Sorry but I think not having _update-info-dir rely on texinfo is not a
>good idea.

To rephrase: I think it is a bad idea to remove dependencies from
_update-info-dir since so many things rely on it.

cgf

Re: New Setup for Cygwin 1.7 on cygwin.com

[Charles Wilson]

Christopher Faylor wrote:

> To rephrase: I think it is a bad idea to remove dependencies from
> _update-info-dir since so many things rely on it.

Unless:

  1) all of _update-info-dir's dependencies are already satisfied by the
Base category

or

  2) we carefully map the dependency chains of the basic system-setup
packages (cygwin, base-*, a few more?) and deliberately exclude them
from getting _update-info-dir added to their dependency list.

or

  3) somehow add a priority scheme to postinstall scripts, so that in
the event of a cycle, setup "starts" traversing the dependency loop at
the package with the highest priority.

In order of least effort to most, I'd vote #1...

--
Chuck

Re: New Setup for Cygwin 1.7 on cygwin.com

[Corinna Vinschen]

On Aug 21 11:12, Charles Wilson wrote:
> Christopher Faylor wrote:
> 
> > To rephrase: I think it is a bad idea to remove dependencies from
> > _update-info-dir since so many things rely on it.
> 
> Unless:
> 
>   1) all of _update-info-dir's dependencies are already satisfied by the
> Base category
> 
> or
> 
>   2) we carefully map the dependency chains of the basic system-setup
> packages (cygwin, base-*, a few more?) and deliberately exclude them
> from getting _update-info-dir added to their dependency list.
> 
> or
> 
>   3) somehow add a priority scheme to postinstall scripts, so that in
> the event of a cycle, setup "starts" traversing the dependency loop at
> the package with the highest priority.
> 
> In order of least effort to most, I'd vote #1...

Full ACK.


Corinna

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

Re: New Setup for Cygwin 1.7 on cygwin.com

[Corinna Vinschen]

On Aug 21 17:20, Corinna Vinschen wrote:
> On Aug 21 11:12, Charles Wilson wrote:
> > Christopher Faylor wrote:
> > 
> > > To rephrase: I think it is a bad idea to remove dependencies from
> > > _update-info-dir since so many things rely on it.
> > 
> > Unless:
> > 
> >   1) all of _update-info-dir's dependencies are already satisfied by the
> > Base category
> > [...]
> > In order of least effort to most, I'd vote #1...
> 
> Full ACK.

There's also the fact that neither bash nor texinfo have postinstall
scripts themselves.  So the dependency from _update-info-dir to bash
and texinfo is fully resolved by having bash and texinfo in the Base
category.


Corinna

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

Re: New Setup for Cygwin 1.7 on cygwin.com

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Corinna Vinschen on 8/21/2008 9:28 AM:
> 
> There's also the fact that neither bash nor texinfo have postinstall
> scripts themselves.

Actually, bash does.  But as of my most recent build, it only ensures that
/dev/stdin and friends exist (hmm, I haven't validated whether that still
works with /etc/fstab...).  In other words, now that /bin/sh is unpacked
prior to any postinstall scripts, it no longer matters whether other
packages' postinstalls run before or after bash, unless their postinstall
wants to use /dev/stdin (unlikely).

- --
Don't work too hard, make some time for fun as well!

Eric Blake             ebb9@byu.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkiuGYcACgkQ84KuGfSFAYD+UQCfdtKxBO/bk2g9Vym6BADmD3eG
8dwAoL7KPgZQ4xZPQMcg4x/02yC2g7ZE
=lSk1
-----END PGP SIGNATURE-----

Re: New Setup for Cygwin 1.7 on cygwin.com

[Christopher Faylor]

On Thu, Aug 21, 2008 at 07:42:31PM -0600, Eric Blake wrote:
>According to Corinna Vinschen on 8/21/2008 9:28 AM:
>>There's also the fact that neither bash nor texinfo have postinstall
>>scripts themselves.
>
>Actually, bash does.  But as of my most recent build, it only ensures
>that /dev/stdin and friends exist (hmm, I haven't validated whether
>that still works with /etc/fstab...).  In other words, now that /bin/sh
>is unpacked prior to any postinstall scripts, it no longer matters
>whether other packages' postinstalls run before or after bash, unless
>their postinstall wants to use /dev/stdin (unlikely).

...and, AFAICT, if you remove _update-info-dir's dependencies, the bash
postinstall still runs first.

cgf

Re: New Setup for Cygwin 1.7 on cygwin.com

[Christopher Faylor]

On Thu, Aug 21, 2008 at 05:20:41PM +0200, Corinna Vinschen wrote:
>On Aug 21 11:12, Charles Wilson wrote:
>> Christopher Faylor wrote:
>> 
>> > To rephrase: I think it is a bad idea to remove dependencies from
>> > _update-info-dir since so many things rely on it.
>> 
>> Unless:
>> 
>>   1) all of _update-info-dir's dependencies are already satisfied by the
>> Base category
>> 
>> or
>> 
>>   2) we carefully map the dependency chains of the basic system-setup
>> packages (cygwin, base-*, a few more?) and deliberately exclude them
>> from getting _update-info-dir added to their dependency list.
>> 
>> or
>> 
>>   3) somehow add a priority scheme to postinstall scripts, so that in
>> the event of a cycle, setup "starts" traversing the dependency loop at
>> the package with the highest priority.
>> 
>> In order of least effort to most, I'd vote #1...
>
>Full ACK.

If only this was a democracy.

I've made the change I mentioned.  Neither bash nor texinfo rely on
_update-info-dir.

cgf

Re: New Setup for Cygwin 1.7 on cygwin.com

[Corinna Vinschen]

On Aug 21 11:37, Christopher Faylor wrote:
> On Thu, Aug 21, 2008 at 05:20:41PM +0200, Corinna Vinschen wrote:
> >On Aug 21 11:12, Charles Wilson wrote:
> >> Christopher Faylor wrote:
> >> 
> >> > To rephrase: I think it is a bad idea to remove dependencies from
> >> > _update-info-dir since so many things rely on it.
> >> 
> >> Unless:
> >> 
> >>   1) all of _update-info-dir's dependencies are already satisfied by the
> >> Base category
> >> 
> >> or
> >> 
> >>   2) we carefully map the dependency chains of the basic system-setup
> >> packages (cygwin, base-*, a few more?) and deliberately exclude them
> >> from getting _update-info-dir added to their dependency list.
> >> 
> >> or
> >> 
> >>   3) somehow add a priority scheme to postinstall scripts, so that in
> >> the event of a cycle, setup "starts" traversing the dependency loop at
> >> the package with the highest priority.
> >> 
> >> In order of least effort to most, I'd vote #1...
> >
> >Full ACK.
> 
> If only this was a democracy.

???

> I've made the change I mentioned.  Neither bash nor texinfo rely on
> _update-info-dir.

I don't think this is the right solution.  How does that help with other
loops?  I only checked packages which were in front of the cygwin
package in the dependency order for a plain Base install.  The list of
dependencies for a full install is much bigger.

You're fixing single symptoms, rather than taking out the core problem.


Corinna

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

Re: New Setup for Cygwin 1.7 on cygwin.com

[Christopher Faylor]

On Thu, Aug 21, 2008 at 05:58:39PM +0200, Corinna Vinschen wrote:
>You're fixing single symptoms, rather than taking out the core problem.

The proposed fix is to remove *valid* dependencies because they are
causing setup.exe to behave in ways that are undesirable.  That is not
an actual fix for the core problem.  It's a band-aid.

If the dependencies for _update-info-dir were removed and someone
carefully unselected everything and selected only, say, bash and
openssh, trusting setup.exe dependency handling, then the end result
would be an _update-info-dir postinstall that displays errors.

If bash was made to not rely on _update-info-dir then there would be no
errors, there would be one less package to download, and "info bash"
would still work but "info" would not.  I think that's a lot more
desirable than a postinstall script that shows inexplicable errors.

cgf

Re: New Setup for Cygwin 1.7 on cygwin.com

[Brian Dessent]

Corinna Vinschen wrote:

> All we did the last couple of days seems to have helped only marginally,
> if at all.  This morning I ran a 1.7 Base install from scratch, and the
> dependency order is still as screwed up as before:

But base-cygwin still has "requires: bash coreutils".  That's just going
to pull in _update-info-dir and mess everything up.  Remove that and we
should be fine without messing with _update-info-dir's requires line.

Brian

Re: New Setup for Cygwin 1.7 on cygwin.com

[Corinna Vinschen]

On Aug 21 18:36, Brian Dessent wrote:
> Corinna Vinschen wrote:
> 
> > All we did the last couple of days seems to have helped only marginally,
> > if at all.  This morning I ran a 1.7 Base install from scratch, and the
> > dependency order is still as screwed up as before:
> 
> But base-cygwin still has "requires: bash coreutils".

No, it hasn't.  I already removed this dependency a week ago.


Corinna

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

Re: New Setup for Cygwin 1.7 on cygwin.com

[Brian Dessent]

Corinna Vinschen wrote:

> No, it hasn't.  I already removed this dependency a week ago.

Perhaps something wonky with unionfs is happening then because I
clearly see it in the setup-2.ini on sourceware at this moment:

[briand@sourceware ~/ftp]$ awk '/^@ base-cygwin$/,/^requires:/' setup-2.ini
@ base-cygwin
sdesc: "Upgrade helper scripts from 1.5.x to 1.7.x"
ldesc: "Upgrade helper scripts from 1.5.x to 1.7.x"
category: Base
requires: bash coreutils

Brian

Re: New Setup for Cygwin 1.7 on cygwin.com

[Corinna Vinschen]

On Aug 22 00:54, Brian Dessent wrote:
> Corinna Vinschen wrote:
> 
> > No, it hasn't.  I already removed this dependency a week ago.
> 
> Perhaps something wonky with unionfs is happening then because I
> clearly see it in the setup-2.ini on sourceware at this moment:
> 
> [briand@sourceware ~/ftp]$ awk '/^@ base-cygwin$/,/^requires:/' setup-2.ini
> @ base-cygwin
> sdesc: "Upgrade helper scripts from 1.5.x to 1.7.x"
> ldesc: "Upgrade helper scripts from 1.5.x to 1.7.x"
> category: Base
> requires: bash coreutils

Gosh.  You're right.  If you look into the setup.hint file, it's not
there:

  $ ls -l release-2/base-cygwin/setup.hint 
  -rw-r--r--  1 cyguser cygwin 119 Aug 15 14:23 release-2/base-cygwin/setup.hint
  $ cat release-2/base-cygwin/setup.hint 
  sdesc: "Upgrade helper scripts from 1.5.x to 1.7.x"
  ldesc: "Upgrade helper scripts from 1.5.x to 1.7.x"
  category: Base
  $

Why didn't upset pick up the change?


Corinna

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

Re: New Setup for Cygwin 1.7 on cygwin.com

[Brian Dessent]

Corinna Vinschen wrote:

> Why didn't upset pick up the change?

Perhaps it has to do with the design of upset being incremental, i.e.
taking the current setup-2.ini as input and applying updates to it
rather than generating it from whole each time.  It might be confused
upon not seeing a "requires:" at all in the .hint and so it leaves the
existing "requires:" in the .ini unchanged.  If this is the case then
listing an explicit empty "requires:" in the .hint would probably work
around it.  If true then it sounds like more of a bug to fix than
something we want to kludge around.

Brian

Re: New Setup for Cygwin 1.7 on cygwin.com

[Corinna Vinschen]

On Aug 22 01:58, Brian Dessent wrote:
> Corinna Vinschen wrote:
> 
> > Why didn't upset pick up the change?
> 
> Perhaps it has to do with the design of upset being incremental, i.e.
> taking the current setup-2.ini as input and applying updates to it
> rather than generating it from whole each time.  It might be confused
> upon not seeing a "requires:" at all in the .hint and so it leaves the
> existing "requires:" in the .ini unchanged.  If this is the case then
> listing an explicit empty "requires:" in the .hint would probably work

I tried that and it helped.

> around it.  If true then it sounds like more of a bug to fix than
> something we want to kludge around.


Corinna

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

Re: New Setup for Cygwin 1.7 on cygwin.com

[Corinna Vinschen]

On Aug 22 11:09, Corinna Vinschen wrote:
> On Aug 22 01:58, Brian Dessent wrote:
> > Corinna Vinschen wrote:
> > 
> > > Why didn't upset pick up the change?
> > 
> > Perhaps it has to do with the design of upset being incremental, i.e.
> > taking the current setup-2.ini as input and applying updates to it
> > rather than generating it from whole each time.  It might be confused
> > upon not seeing a "requires:" at all in the .hint and so it leaves the
> > existing "requires:" in the .ini unchanged.  If this is the case then
> > listing an explicit empty "requires:" in the .hint would probably work
> 
> I tried that and it helped.

Still no go.  I checked setup-2.ini and it looks almost correct now.
Still, the order in setup is screwed:

warning: LOG: 1 Dependency order of packages: libintl3 texinfo
_update-info-dir gawk tzcode libiconv2 coreutils terminfo libncurses8
libreadline6 bash base-cygwin base-passwd cygwin libintl8 alternatives
ash findutils sed base-files libbz2_1 bzip2 libpopt0 cygutils groff
gzip termcap libpcre0 less man cygwin-doc editrights grep ipc-utils
login rebase run tar which

I checked the requirements again and tried to do my own hand-crafted
dependency ordering with the least set of depending packages.

base-cygwin     : NO requires
base-passwd     : base-cygwin
cygwin          : base-passwd base-cygwin
libiconv2       : cygwin
libintl8        : cygwin libiconv2
libreadline6    : cygwin libncurses8
bash            : cygwin libintl8 libreadline6 (NO _update-info-dir)
libintl3        : cygwin libiconv2
gawk            : bash cygwin libintl8 _update-info-dir
tzcode          : cygwin bash gawk
coreutils       : bash cygwin libiconv2 libintl8 tzcode _update-info-dir
terminfo        : bash coreutils
libncurses8     : cygwin terminfo
texinfo         : cygwin libiconv2 libintl3 libncurses8 (NO _update-info-dir)
_update-info-dir: texinfo bash

As you can see, there are four loops:

  bash -> libreadline6 -> libncurses8 -> terminfo -> bash

  bash -> libreadline6 -> libncurses8 -> terminfo -> coreutils -> bash

  _update-info-dir -> texinfo -> libncurses8 -> terminfo
  -> coreutils -> _update-info-dir

  _update-info-dir -> texinfo -> libncurses8 -> terminfo
  -> coreutils -> tzcode -> gawk -> _update-info-dir

The crucial package here is apparently terminfo.  The dependency
to bash and coreutils is based on a really tiny script which tries
to create a symlink /usr/lib/terminfo pointing to /usr/share/terminfo.
If the terminfo package would bring this symlink right in the tar
file, the postinstall script could go away, and the dependencies
to bash and coreutils with it.  If terminfo doesn't depend on bash
and coreutils, the dependency order would be changed to:

base-cygwin     : NO requires
terminfo        : NO requires
base-passwd     : base-cygwin
cygwin          : base-passwd base-cygwin
libncurses8     : cygwin terminfo
libiconv2       : cygwin
libintl8        : cygwin libiconv2
libreadline6    : cygwin libncurses8
bash            : cygwin libintl8 libreadline6 (NO _update-info-dir)
libintl3        : cygwin libiconv2
texinfo         : cygwin libiconv2 libintl3 libncurses8 (NO _update-info-dir)
_update-info-dir: texinfo bash
gawk            : bash cygwin libintl8 _update-info-dir
tzcode          : cygwin bash gawk
coreutils       : bash cygwin libiconv2 libintl8 tzcode _update-info-dir

which is a neat tree without loops.

I'm nevertheless wondering about the dependency algorithm in setup.
From a "common sense" perspective, one would expect that the fact that
all packages depend on cygwin should have *some* effect.  The above
result looks rather unstable.  I'm under the impression the algorithm
isn't quite complete.


Corinna

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

Re: New Setup for Cygwin 1.7 on cygwin.com

[Christopher Faylor]

On Mon, Aug 25, 2008 at 12:26:02PM +0200, Corinna Vinschen wrote:
>On Aug 22 11:09, Corinna Vinschen wrote:
>> On Aug 22 01:58, Brian Dessent wrote:
>> > Corinna Vinschen wrote:
>> > 
>> > > Why didn't upset pick up the change?
>> > 
>> > Perhaps it has to do with the design of upset being incremental, i.e.
>> > taking the current setup-2.ini as input and applying updates to it
>> > rather than generating it from whole each time.  It might be confused
>> > upon not seeing a "requires:" at all in the .hint and so it leaves the
>> > existing "requires:" in the .ini unchanged.  If this is the case then
>> > listing an explicit empty "requires:" in the .hint would probably work
>> 
>> I tried that and it helped.
>
>Still no go.  I checked setup-2.ini and it looks almost correct now.
>Still, the order in setup is screwed:
>
>warning: LOG: 1 Dependency order of packages: libintl3 texinfo
>_update-info-dir gawk tzcode libiconv2 coreutils terminfo libncurses8
>libreadline6 bash base-cygwin base-passwd cygwin libintl8 alternatives
>ash findutils sed base-files libbz2_1 bzip2 libpopt0 cygutils groff
>gzip termcap libpcre0 less man cygwin-doc editrights grep ipc-utils
>login rebase run tar which
>
>I checked the requirements again and tried to do my own hand-crafted
>dependency ordering with the least set of depending packages.
>
>base-cygwin     : NO requires
>base-passwd     : base-cygwin
>cygwin          : base-passwd base-cygwin
>libiconv2       : cygwin
>libintl8        : cygwin libiconv2
>libreadline6    : cygwin libncurses8
>bash            : cygwin libintl8 libreadline6 (NO _update-info-dir)
>libintl3        : cygwin libiconv2
>gawk            : bash cygwin libintl8 _update-info-dir
>tzcode          : cygwin bash gawk
>coreutils       : bash cygwin libiconv2 libintl8 tzcode _update-info-dir
>terminfo        : bash coreutils
>libncurses8     : cygwin terminfo
>texinfo         : cygwin libiconv2 libintl3 libncurses8 (NO _update-info-dir)
>_update-info-dir: texinfo bash
>
>As you can see, there are four loops:
>
>  bash -> libreadline6 -> libncurses8 -> terminfo -> bash
>
>  bash -> libreadline6 -> libncurses8 -> terminfo -> coreutils -> bash
>
>  _update-info-dir -> texinfo -> libncurses8 -> terminfo
>  -> coreutils -> _update-info-dir
>
>  _update-info-dir -> texinfo -> libncurses8 -> terminfo
>  -> coreutils -> tzcode -> gawk -> _update-info-dir
>
>The crucial package here is apparently terminfo.  The dependency
>to bash and coreutils is based on a really tiny script which tries
>to create a symlink /usr/lib/terminfo pointing to /usr/share/terminfo.
>If the terminfo package would bring this symlink right in the tar
>file, the postinstall script could go away, and the dependencies
>to bash and coreutils with it.  If terminfo doesn't depend on bash
>and coreutils, the dependency order would be changed to:
>
>base-cygwin     : NO requires
>terminfo        : NO requires
>base-passwd     : base-cygwin
>cygwin          : base-passwd base-cygwin
>libncurses8     : cygwin terminfo
>libiconv2       : cygwin
>libintl8        : cygwin libiconv2
>libreadline6    : cygwin libncurses8
>bash            : cygwin libintl8 libreadline6 (NO _update-info-dir)
>libintl3        : cygwin libiconv2
>texinfo         : cygwin libiconv2 libintl3 libncurses8 (NO _update-info-dir)
>_update-info-dir: texinfo bash
>gawk            : bash cygwin libintl8 _update-info-dir
>tzcode          : cygwin bash gawk
>coreutils       : bash cygwin libiconv2 libintl8 tzcode _update-info-dir
>
>which is a neat tree without loops.
>
>I'm nevertheless wondering about the dependency algorithm in setup.
From a "common sense" perspective, one would expect that the fact that
>all packages depend on cygwin should have *some* effect.  The above
>result looks rather unstable.  I'm under the impression the algorithm
>isn't quite complete.

It looks that way.

Making tweaks by removing valid dependencies in the hopes of improving
things is not going to be a win in the long run.  We seem to be in a
situation that is only solvable by changing setup.exe.

cgf

Re: New Setup for Cygwin 1.7 on cygwin.com

[Christopher Faylor]

On Mon, Aug 25, 2008 at 10:33:00AM -0400, Christopher Faylor wrote:
>Making tweaks by removing valid dependencies in the hopes of improving
>things is not going to be a win in the long run.  We seem to be in a
>situation that is only solvable by changing setup.exe.

That said, however, I can manage to get base-cygwin first in the
dependency order by changing all of the "requires: ...cygwin" to
"requires: ...base-cygwin".  base-passwd is still off in the weeds
somewhere.  Maybe those two packages should just be combined?

cgf

Re: New Setup for Cygwin 1.7 on cygwin.com

[Corinna Vinschen]

On Aug 25 11:27, Christopher Faylor wrote:
> On Mon, Aug 25, 2008 at 10:33:00AM -0400, Christopher Faylor wrote:
> >Making tweaks by removing valid dependencies in the hopes of improving
> >things is not going to be a win in the long run.  We seem to be in a
> >situation that is only solvable by changing setup.exe.
> 
> That said, however, I can manage to get base-cygwin first in the
> dependency order by changing all of the "requires: ...cygwin" to
> "requires: ...base-cygwin".  base-passwd is still off in the weeds
> somewhere.  Maybe those two packages should just be combined?

The terminfo change would be much simpler.  Everything else seems
to fall into place then.


Corinna

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

Re: New Setup for Cygwin 1.7 on cygwin.com

[Christopher Faylor]

On Mon, Aug 25, 2008 at 05:37:53PM +0200, Corinna Vinschen wrote:
>On Aug 25 11:27, Christopher Faylor wrote:
>> On Mon, Aug 25, 2008 at 10:33:00AM -0400, Christopher Faylor wrote:
>> >Making tweaks by removing valid dependencies in the hopes of improving
>> >things is not going to be a win in the long run.  We seem to be in a
>> >situation that is only solvable by changing setup.exe.
>> 
>> That said, however, I can manage to get base-cygwin first in the
>> dependency order by changing all of the "requires: ...cygwin" to
>> "requires: ...base-cygwin".  base-passwd is still off in the weeds
>> somewhere.  Maybe those two packages should just be combined?
>
>The terminfo change would be much simpler.  Everything else seems
>to fall into place then.

I'd consider changes like the terminfo change a rather fragile way of
fixing the problem.  It looks like all we'd need is for libintl8 to add
similar dependencies and everything would fall apart again.  And we
wouldn't know about it for some time.

Creating a package which is designed to be relied on by everyone and is
a "terminal node" should ensure that it is always run first.  upset could
be modified to make sure that everything relies on base-cygwin, too.

Btw, did you try running setup after removing terminfo?  I get this
order (from setup.log.full):

    Dependency order of packages: terminfo libintl3 texinfo
    _update-info-dir gawk tzcode libiconv2 coreutils libncurses8
    libreadline6 bash base-cygwin base-passwd cygwin libintl8 alternatives
    ash findutils sed base-files libbz2_1 bzip2 libpopt0 cygutils groff
    gzip termcap libpcre0 less man cygwin-doc editrights grep ipc-utils
    login rebase run tar which

If I add a dependency to cygwin, the depedency moves later in the list
but it still is before base-cygwin, which makes no sense to me at all.

cgf

Re: New Setup for Cygwin 1.7 on cygwin.com

[Corinna Vinschen]

On Aug 25 11:57, Christopher Faylor wrote:
> On Mon, Aug 25, 2008 at 05:37:53PM +0200, Corinna Vinschen wrote:
> >On Aug 25 11:27, Christopher Faylor wrote:
> >> On Mon, Aug 25, 2008 at 10:33:00AM -0400, Christopher Faylor wrote:
> >> >Making tweaks by removing valid dependencies in the hopes of improving
> >> >things is not going to be a win in the long run.  We seem to be in a
> >> >situation that is only solvable by changing setup.exe.
> >> 
> >> That said, however, I can manage to get base-cygwin first in the
> >> dependency order by changing all of the "requires: ...cygwin" to
> >> "requires: ...base-cygwin".  base-passwd is still off in the weeds
> >> somewhere.  Maybe those two packages should just be combined?
> >
> >The terminfo change would be much simpler.  Everything else seems
> >to fall into place then.
> 
> I'd consider changes like the terminfo change a rather fragile way of
> fixing the problem.  It looks like all we'd need is for libintl8 to add
> similar dependencies and everything would fall apart again.  And we
> wouldn't know about it for some time.
> 
> Creating a package which is designed to be relied on by everyone and is
> a "terminal node" should ensure that it is always run first.  upset could
> be modified to make sure that everything relies on base-cygwin, too.
> 
> Btw, did you try running setup after removing terminfo?  I get this

I don't understand.  Removing terminfo from where?  If you mean,
removing its dependencies...

> order (from setup.log.full):
> 
>     Dependency order of packages: terminfo libintl3 texinfo
>     _update-info-dir gawk tzcode libiconv2 coreutils libncurses8
>     libreadline6 bash base-cygwin base-passwd cygwin libintl8 alternatives
>     ash findutils sed base-files libbz2_1 bzip2 libpopt0 cygutils groff
>     gzip termcap libpcre0 less man cygwin-doc editrights grep ipc-utils
>     login rebase run tar which
> 
> If I add a dependency to cygwin, the depedency moves later in the list
> but it still is before base-cygwin, which makes no sense to me at all.

...then the result is most weird.  The algorithm in setup.exe appears
more and more unreliable.


Corinna

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

Re: New Setup for Cygwin 1.7 on cygwin.com

[Christopher Faylor]

On Mon, Aug 25, 2008 at 06:16:34PM +0200, Corinna Vinschen wrote:
>On Aug 25 11:57, Christopher Faylor wrote:
>> On Mon, Aug 25, 2008 at 05:37:53PM +0200, Corinna Vinschen wrote:
>> >On Aug 25 11:27, Christopher Faylor wrote:
>> >> On Mon, Aug 25, 2008 at 10:33:00AM -0400, Christopher Faylor wrote:
>> >> >Making tweaks by removing valid dependencies in the hopes of improving
>> >> >things is not going to be a win in the long run.  We seem to be in a
>> >> >situation that is only solvable by changing setup.exe.
>> >> 
>> >> That said, however, I can manage to get base-cygwin first in the
>> >> dependency order by changing all of the "requires: ...cygwin" to
>> >> "requires: ...base-cygwin".  base-passwd is still off in the weeds
>> >> somewhere.  Maybe those two packages should just be combined?
>> >
>> >The terminfo change would be much simpler.  Everything else seems
>> >to fall into place then.
>> 
>> I'd consider changes like the terminfo change a rather fragile way of
>> fixing the problem.  It looks like all we'd need is for libintl8 to add
>> similar dependencies and everything would fall apart again.  And we
>> wouldn't know about it for some time.
>> 
>> Creating a package which is designed to be relied on by everyone and is
>> a "terminal node" should ensure that it is always run first.  upset could
>> be modified to make sure that everything relies on base-cygwin, too.
>> 
>> Btw, did you try running setup after removing terminfo?  I get this
>
>I don't understand.  Removing terminfo from where?  If you mean,
>removing its dependencies...

>> order (from setup.log.full):
>> 
>>     Dependency order of packages: terminfo libintl3 texinfo
                                     ^^^^^^^^

I meant removing the dependencies.  Doing so doesn't seem to solve any
problems.

cgf

Re: New Setup for Cygwin 1.7 on cygwin.com

[Corinna Vinschen]

On Aug 25 13:22, Christopher Faylor wrote:
> On Mon, Aug 25, 2008 at 06:16:34PM +0200, Corinna Vinschen wrote:
> >On Aug 25 11:57, Christopher Faylor wrote:
> >> On Mon, Aug 25, 2008 at 05:37:53PM +0200, Corinna Vinschen wrote:
> >> >On Aug 25 11:27, Christopher Faylor wrote:
> >> >> On Mon, Aug 25, 2008 at 10:33:00AM -0400, Christopher Faylor wrote:
> >> >> >Making tweaks by removing valid dependencies in the hopes of improving
> >> >> >things is not going to be a win in the long run.  We seem to be in a
> >> >> >situation that is only solvable by changing setup.exe.
> >> >> 
> >> >> That said, however, I can manage to get base-cygwin first in the
> >> >> dependency order by changing all of the "requires: ...cygwin" to
> >> >> "requires: ...base-cygwin".  base-passwd is still off in the weeds
> >> >> somewhere.  Maybe those two packages should just be combined?
> >> >
> >> >The terminfo change would be much simpler.  Everything else seems
> >> >to fall into place then.
> >> 
> >> I'd consider changes like the terminfo change a rather fragile way of
> >> fixing the problem.  It looks like all we'd need is for libintl8 to add
> >> similar dependencies and everything would fall apart again.  And we
> >> wouldn't know about it for some time.
> >> 
> >> Creating a package which is designed to be relied on by everyone and is
> >> a "terminal node" should ensure that it is always run first.  upset could
> >> be modified to make sure that everything relies on base-cygwin, too.
> >> 
> >> Btw, did you try running setup after removing terminfo?  I get this
> >
> >I don't understand.  Removing terminfo from where?  If you mean,
> >removing its dependencies...
> 
> >> order (from setup.log.full):
> >> 
> >>     Dependency order of packages: terminfo libintl3 texinfo
>                                      ^^^^^^^^
> 
> I meant removing the dependencies.  Doing so doesn't seem to solve any
> problems.

I looked a while into the algorithm doing the dependency ordering.  What
it does is to create an ordered list sorted by using the algorithm to
find the strongly connected components in a directed graph.  The problem
is that this algorithm works fine and creates a nice dependeny ordered
list unless there are loops in the dependencies.  In this case you just
get a list of strongly connected components in arbitrary order.

Today I tried a simple trick.  The algorithm now iterates through the
package list twice.  The first run only visits the packages which itself
have no dependencies and puts them first in the dependency ordered list.
The second run then visits all other packages.  I didn't expect a lot,
just a bit better.  But the resul was surprisingly good:

  Dependency order of packages: base-cygwin base-passwd cygwin libiconv2
  libintl8 libintl3 alternatives texinfo _update-info-dir gawk tzcode
  coreutils terminfo libncurses8 libreadline6 bash ash findutils sed
  base-files libbz2_1 bzip2 libpopt0 cygutils groff gzip termcap
  libpcre0 less man cygwin-doc editrights grep ipc-utils login rebase
  run tar which

Maybe that's just coincidence.  I think I'll apply this patch and
tomorrow I'll try to add another loop between the above loops.  That
loop would only visit packages which have exactly one dependency, and
that dependency is to one of the packages which have no dependencies.
Or, maybe just visiting packages which have exactly one dependency, no
matter what.

Anybody having another funny idea?


Corinna

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

Re: New Setup for Cygwin 1.7 on cygwin.com

[Christopher Faylor]

On Wed, Aug 27, 2008 at 07:14:32PM +0200, Corinna Vinschen wrote:
>Anybody having another funny idea?

Your patch may be a good idea but I still think that base-cygwin (and
maybe base-passwd) should be a dependency of every package in the
distribution.  I think that every package which currently relies on
cygwin should instead rely on base-cygwin and every package which does
not have a cygwin dependency (and there are a quite a few of those)
should be forced to rely on base-cygwin.

In my experiments, that forces base-cygwin first in the dependency order
without any setup.exe changes required.

cgf

Re: New Setup for Cygwin 1.7 on cygwin.com

[Corinna Vinschen]

On Aug 27 14:35, Christopher Faylor wrote:
> On Wed, Aug 27, 2008 at 07:14:32PM +0200, Corinna Vinschen wrote:
> >Anybody having another funny idea?
> 
> Your patch may be a good idea but I still think that base-cygwin (and
> maybe base-passwd) should be a dependency of every package in the
> distribution.  I think that every package which currently relies on
> cygwin should instead rely on base-cygwin and every package which does
> not have a cygwin dependency (and there are a quite a few of those)
> should be forced to rely on base-cygwin.
> 
> In my experiments, that forces base-cygwin first in the dependency order
> without any setup.exe changes required.

That really shouldn't be necessary.  cygwin is the only package
depending on base-cygwin and if every other package depends on cygwin,
base-cygwin should go first, too.  If it doesn't, it's still a problem
of the dependency algorithm.  If we can't make sure that the algorithm
works as we need it to, it would be a lot of change with questionable
outcome.  You'd never know if a new package or a different package
selection wouldn't screw up the order again.


Corinna

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

Re: New Setup for Cygwin 1.7 on cygwin.com

[Christopher Faylor]

On Thu, Aug 28, 2008 at 09:37:10AM +0200, Corinna Vinschen wrote:
>On Aug 27 14:35, Christopher Faylor wrote:
>> On Wed, Aug 27, 2008 at 07:14:32PM +0200, Corinna Vinschen wrote:
>> >Anybody having another funny idea?
>> 
>> Your patch may be a good idea but I still think that base-cygwin (and
>> maybe base-passwd) should be a dependency of every package in the
>> distribution.  I think that every package which currently relies on
>> cygwin should instead rely on base-cygwin and every package which does
>> not have a cygwin dependency (and there are a quite a few of those)
>> should be forced to rely on base-cygwin.
>> 
>> In my experiments, that forces base-cygwin first in the dependency order
>> without any setup.exe changes required.
>
>That really shouldn't be necessary.  cygwin is the only package
>depending on base-cygwin and if every other package depends on cygwin,
>base-cygwin should go first, too.

But, as I said, every package does not rely on cygwin.  Perhaps if every
package did rely on cygwin that would solve a problem but, in reality,
every package *does* rely on what base-cygwin does and doesn't actually
rely on cygwin1.dll.

>If it doesn't, it's still a problem of the dependency algorithm.  If we
>can't make sure that the algorithm works as we need it to, it would be
>a lot of change with questionable outcome.  You'd never know if a new
>package or a different package selection wouldn't screw up the order
>again.

I'm rather familiar with this argument since I've been making it
consistently in this mailing list whenever you want to remove a valid
dependency to tweak order.

Your approach relies on the fact what are "leaf nodes" today will always
be "leaf nodes" tomorrow so there is still the potential of questionable
outcome in the future.  As I said, I'm all in favor of improving
setup.exe's algorithm but I think that the dependencies in setup.ini
should be accurate too.  They aren't now, for cygwin 1.7.

I'm not talking about something that every package maintainer has to
remember here.  I'm talking about adding logic to upset to ensure that a
package is always included as a dependency.  I'll do that in the next
couple of days.

(And, no, I'm not going to special case "cygwin" or "base-cygwin")

cgf

Re: New Setup for Cygwin 1.7 on cygwin.com

[Christopher Faylor]

On Thu, Aug 28, 2008 at 10:17:49AM -0400, Christopher Faylor wrote:
>But, as I said, every package does not rely on cygwin.  Perhaps if every
>package did rely on cygwin that would solve a problem but, in reality,
>every package *does* rely on what base-cygwin does and doesn't actually
>rely on cygwin1.dll.

Adding a 'cygwin' dependency whereever one is missing causes this
dependency order:

base-cygwin base-passwd cygwin libiconv2 libintl8 libintl3 alternatives terminfo libncurses8 libreadline6 bash ash texinfo _update-info-dir gawk tzcode coreutils findutils sed base-files libbz2_1 bzip2 libpopt0 cygutils groff gzip termcap libpcre0 less man cygwin-doc editrights grep ipc-utils login rebase run tar which

cgf

Re: New Setup for Cygwin 1.7 on cygwin.com

[Christopher Faylor]

On Thu, Aug 28, 2008 at 11:01:10AM -0400, Christopher Faylor wrote:
>On Thu, Aug 28, 2008 at 10:17:49AM -0400, Christopher Faylor wrote:
>>But, as I said, every package does not rely on cygwin.  Perhaps if every
>>package did rely on cygwin that would solve a problem but, in reality,
>>every package *does* rely on what base-cygwin does and doesn't actually
>>rely on cygwin1.dll.
>
>Adding a 'cygwin' dependency whereever one is missing causes this
>dependency order:
>
>base-cygwin base-passwd cygwin libiconv2 libintl8 libintl3 alternatives terminfo libncurses8 libreadline6 bash ash texinfo _update-info-dir gawk tzcode coreutils findutils sed base-files libbz2_1 bzip2 libpopt0 cygutils groff gzip termcap libpcre0 less man cygwin-doc editrights grep ipc-utils login rebase run tar which

I've modified cygwin's setup.hint to force it to be added as a
dependency for every package and modified the setup.hint for base-passwd
and base-cygwin to avoid the auto-dependency.

(I also once again found a bug in upset's auto dependency handling)

setup.log.full seems to confirm that things are now run in the correct
order.

Although I still think that relying on cygwin is not strictly correct, I
think this might ensure the right package ordering going forward.

cgf

Re: New Setup for Cygwin 1.7 on cygwin.com

[Corinna Vinschen]

On Aug 28 15:04, Christopher Faylor wrote:
> I've modified cygwin's setup.hint to force it to be added as a
> dependency for every package and modified the setup.hint for base-passwd
> and base-cygwin to avoid the auto-dependency.
> 
> (I also once again found a bug in upset's auto dependency handling)
> 
> setup.log.full seems to confirm that things are now run in the correct
> order.
> 
> Although I still think that relying on cygwin is not strictly correct, I
> think this might ensure the right package ordering going forward.

Cool, thanks.


Corinna

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

Re: New Setup for Cygwin 1.7 on cygwin.com

[Ralph Hempel]

Corinna Vinschen wrote:

> I looked a while into the algorithm doing the dependency ordering.  What
> it does is to create an ordered list sorted by using the algorithm to
> find the strongly connected components in a directed graph.  The problem
> is that this algorithm works fine and creates a nice dependeny ordered
> list unless there are loops in the dependencies.  In this case you just
> get a list of strongly connected components in arbitrary order.

<SNIP>

> Anybody having another funny idea?

What about detecting a dependency loop by checking to see if the next 
package in the dependency list is already in the list. If there's a loop
then stop.

Or is it possible for there to be new nodes after the first duplicate
dependency?

Ralph

Re: New Setup for Cygwin 1.7 on cygwin.com

[Corinna Vinschen]

On Aug 27 15:07, Ralph Hempel wrote:
> Corinna Vinschen wrote:
>
>> I looked a while into the algorithm doing the dependency ordering.  What
>> it does is to create an ordered list sorted by using the algorithm to
>> find the strongly connected components in a directed graph.  The problem
>> is that this algorithm works fine and creates a nice dependeny ordered
>> list unless there are loops in the dependencies.  In this case you just
>> get a list of strongly connected components in arbitrary order.
>
> <SNIP>
>
>> Anybody having another funny idea?
>
> What about detecting a dependency loop by checking to see if the next 
> package in the dependency list is already in the list. If there's a loop
> then stop.

Dependency loops are already detected, just the result is less than
desirable.  It's a stadard problem of loops in directed graphs.  There's
no way to create a topological sort order and the result of any sort
algorithm is basically not determinate.  So you have to put some
additional heuristic into the algorithm to get a sort order you desire.


Corinna

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

Re: New Setup for Cygwin 1.7 on cygwin.com

[Ralph Hempel]

Corinna Vinschen wrote:
> On Aug 27 15:07, Ralph Hempel wrote:

> Dependency loops are already detected, just the result is less than
> desirable.  It's a stadard problem of loops in directed graphs.  There's
> no way to create a topological sort order and the result of any sort
> algorithm is basically not determinate.  So you have to put some
> additional heuristic into the algorithm to get a sort order you desire.

Ah. Perhaps I should dig into Volume 3 of my Knuth books.....

For what it's worth, I think that your approach of tackling the
algorithm and making it run correctly is going to get a better
end result than hacking at the description file.

Cheers, Ralph

Re: New Setup for Cygwin 1.7 on cygwin.com

[Corinna Vinschen]

On Aug 25 11:57, Christopher Faylor wrote:
> On Mon, Aug 25, 2008 at 05:37:53PM +0200, Corinna Vinschen wrote:
> >On Aug 25 11:27, Christopher Faylor wrote:
> >> On Mon, Aug 25, 2008 at 10:33:00AM -0400, Christopher Faylor wrote:
> >> >Making tweaks by removing valid dependencies in the hopes of improving
> >> >things is not going to be a win in the long run.  We seem to be in a
> >> >situation that is only solvable by changing setup.exe.
> >> 
> >> That said, however, I can manage to get base-cygwin first in the
> >> dependency order by changing all of the "requires: ...cygwin" to
> >> "requires: ...base-cygwin".  base-passwd is still off in the weeds
> >> somewhere.  Maybe those two packages should just be combined?
> >
> >The terminfo change would be much simpler.  Everything else seems
> >to fall into place then.
> 
> I'd consider changes like the terminfo change a rather fragile way of
> fixing the problem.

You know I agree wholeheartedly that we must look into setup's
dependency algorithm in the first place, but the change to terminfo
would make sense, nevertheless.  The postinstall script is just
adding a static symlink which could easily be done by adding the
symlink to the tar archive directly.

Chuck, would you mind to do this change, even though it doesn't
help with setup's idea of the dependency order right now?


Corinna

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

Re: New Setup for Cygwin 1.7 on cygwin.com

[Charles Wilson]

Corinna Vinschen wrote:
> Chuck, would you mind to do this change, even though it doesn't
> help with setup's idea of the dependency order right now?

Sure, no problem. It's been almost two years since the last update, so I
need to resync with upstream ncurses anyway.  BTW, most linux distros
split the terminfo database into a default set, and then an -extraterms
that has the bulk of the terminal definitions.  Does that sound like a
good idea for us, too?

--
Chuck

Re: New Setup for Cygwin 1.7 on cygwin.com

[Corinna Vinschen]

On Aug 26 08:00, Charles Wilson wrote:
> Corinna Vinschen wrote:
> > Chuck, would you mind to do this change, even though it doesn't
> > help with setup's idea of the dependency order right now?
> 
> Sure, no problem. It's been almost two years since the last update, so I
> need to resync with upstream ncurses anyway.  BTW, most linux distros
> split the terminfo database into a default set, and then an -extraterms
> that has the bulk of the terminal definitions.  Does that sound like a
> good idea for us, too?

If it's good for Linux...

It would just be a pity to find the cygwin terminfo file only in the
-extraterms package ;)


Corinna


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

Re: New Setup for Cygwin 1.7 on cygwin.com

[Christopher Faylor]

On Fri, Aug 22, 2008 at 01:58:48AM -0700, Brian Dessent wrote:
>Corinna Vinschen wrote:
>
>> Why didn't upset pick up the change?
>
>Perhaps it has to do with the design of upset being incremental, i.e.
>taking the current setup-2.ini as input and applying updates to it
>rather than generating it from whole each time.  It might be confused
>upon not seeing a "requires:" at all in the .hint and so it leaves the
>existing "requires:" in the .ini unchanged.  If this is the case then
>listing an explicit empty "requires:" in the .hint would probably work
>around it.  If true then it sounds like more of a bug to fix than
>something we want to kludge around.

It's not really a bug but it isn't needed anymore.  If there are no
dependencies in setup.hint but there are dependencies in setup.ini then
it's assumed that setup.hint is incomplete.

I started looking into removing that behavior last weekend but it never
dawned on me that this is what was happening here.  In theory all that
you have to do is remove the -u option when generating setup so that it
doesn't initially read setup.ini but, when I did that, the resulting
setup.ini was very different and I haven't completed figuring out why.

cgf

Re: New Setup for Cygwin 1.7 on cygwin.com

[Corinna Vinschen]

On Aug 20 12:17, Charles Wilson wrote:
> This doesn't solve the loop back to cygwin/bash with base-*:
> 
>    base-passwd, setup.hint:
>       requries: cygwin bash
>       NOTE: uses coreutils (cp, rm, chmod) and sed, but
>             does not include them in its requires:.

I'm only looking for the 1.7 dependencies since they are more important
due to fstab (and here especially the /usr/bin and /usr/lib mounts)
created by base-cygwin.

Here's the problem:  There *are* circular dependencies we can't get rid
of.  base-cygwin must run first but requires a shell.  Those circular
dependency problem exists practically in all distros, not only in
Cygwin.

The general idea is that a distro has some sort of base installation,
a set of packages which *must* be installed for the distro to install
correctly.  In Cygwin, that's what the Base category is for.  What we
just have to do is to make sure that the dependencies of all packages in
the Base category make sense.


Corinna

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

Re: New Setup for Cygwin 1.7 on cygwin.com

[Brian Dessent]

Christopher Faylor wrote:

> I thought the whole point was to install cygwin first.  How can you run base
> packages first in a new install when there is no cygwin1.dll?

The ordering only has meaning in the context of running postinstall
scripts, as the postinstall phase doesn't start until after all files
from all packages have been unpacked.

Brian

Re: New Setup for Cygwin 1.7 on cygwin.com

[Christopher Faylor]

On Wed, Aug 20, 2008 at 08:27:11AM -0700, Brian Dessent wrote:
>Christopher Faylor wrote:
>
>> I thought the whole point was to install cygwin first.  How can you run base
>> packages first in a new install when there is no cygwin1.dll?
>
>The ordering only has meaning in the context of running postinstall
>scripts, as the postinstall phase doesn't start until after all files
>from all packages have been unpacked.

Ok.  I thought I had a scenario in mind where install order made a
different but you (and Corinna) are right.  It shouldn't make a
difference.

Sorry for the noise.

cgf

Re: New Setup for Cygwin 1.7 on cygwin.com

[Corinna Vinschen]

On Aug 15 07:16, Eric Blake wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> According to Corinna Vinschen on 8/15/2008 7:13 AM:
> >>
> >> So, how can we make sure that the 000-cygwin-post-install.sh script
> >> from the base-cygwin package runs as the first script?  Does it work
> >> to make bash depend on base-cygwin?
> > 
> > Eric?  Is the latter feasible?  I created the 000-cygwin-post-install.sh
> > in a way so that it only requires bash itself, not any coreutils tool.
> 
> I don't know setup.exe well enough to say if that extra dependency will
> help, but a) it can't hurt, and b) it's worth a shot.  I've tweaked the
> setup.hint in release-2 accordingly.

I removed this again.  As long as we have circular dependencies, it
doesn't look like a solid solution.


Corinna

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

Re: New Setup for Cygwin 1.7 on cygwin.com

[Dr. Volker Zell]

>>>>> Corinna Vinschen writes:

    > Hi,
    > I just uploaded a new setup-1.7.exe to install Cygwin 1.7.

Any idea why I have two user entries for my account in /etc/passwd after
installing a base 1.7 system ?

vzell:unused:1003:513:Dr. Volker Zell,U-XP\vzell,S-1-5-21-484763869-1214440339-839522115-1003:/home/vzell:/bin/bash
vzell:unused:11003:10545:U-XP\vzell,S-1-5-21-484763869-1214440339-839522115-1003:/cygdrive/d/home/vzell:/bin/bash

Ciao
  Volker
  

Re: New Setup for Cygwin 1.7 on cygwin.com

[Corinna Vinschen]

On Aug 15 12:14, Dr. Volker Zell wrote:
> >>>>> Corinna Vinschen writes:
> 
>     > Hi,
>     > I just uploaded a new setup-1.7.exe to install Cygwin 1.7.
> 
> Any idea why I have two user entries for my account in /etc/passwd after
> installing a base 1.7 system ?
> 
> vzell:unused:1003:513:Dr. Volker Zell,U-XP\vzell,S-1-5-21-484763869-1214440339-839522115-1003:/home/vzell:/bin/bash
> vzell:unused:11003:10545:U-XP\vzell,S-1-5-21-484763869-1214440339-839522115-1003:/cygdrive/d/home/vzell:/bin/bash

mkpasswd -l -c prints both entries.  Looks like some changes to mkpasswd
are necessary.

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

Re: New Setup for Cygwin 1.7 on cygwin.com

[Dr. Volker Zell]

>>>>> Corinna Vinschen writes:

    > Hi,
    > I just uploaded a new setup-1.7.exe to install Cygwin 1.7.


vzell@xp /
$ ls -lt
ls: reading directory .: Bad address
total 6
drwxrwxrwt+ 1 vzell Users    0 Aug 15 12:22 tmp
drwxr-xr-x+ 1 vzell Users    0 Aug 15 10:54 dev
drwxrwxrwx+ 1 vzell None     0 Aug 15 10:43 home
-rwxr-xr-x  1 vzell Users   61 Aug 15 10:42 Cygwin.bat
-rwxr-xr-x  1 vzell Users 7022 Aug 15 10:42 Cygwin.ico
drwxr-xr-x+ 1 vzell Users    0 Aug 15 10:41 etc
drwxr-xr-x+ 1 vzell Users    0 Aug 15 10:41 cygdrive             <-- Is this directory really needed
lrwxrwxrwx  1 vzell Users   17 Aug 15 10:41 terminfo -> ../share/terminfo
drwxr-xr-x+ 1 vzell Users    0 Aug 15 10:41 var
drwxr-xr-x+ 1 vzell Users    0 Aug 15 10:41 bin
drwxr-xr-x+ 1 vzell Users    0 Aug 15 10:40 lib
drwxr-xr-x+ 1 vzell Users    0 Aug 15 10:39 usr
dr-xr-xr-x  8 vzell None     0 Dec  1  2006 proc
    
Ciao
  Volker

Re: New Setup for Cygwin 1.7 on cygwin.com

[Corinna Vinschen]

On Aug 15 13:46, Dr. Volker Zell wrote:
> >>>>> Corinna Vinschen writes:
> 
>     > Hi,
>     > I just uploaded a new setup-1.7.exe to install Cygwin 1.7.
> 
> 
> vzell@xp /
> $ ls -lt
> ls: reading directory .: Bad address

Is that just an accident or are you trying to tell me something else
with this mail?  Where's the message?


Corinna

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

Re: New Setup for Cygwin 1.7 on cygwin.com

[Corinna Vinschen]

On Aug 15 13:56, Corinna Vinschen wrote:
> On Aug 15 13:46, Dr. Volker Zell wrote:
> > >>>>> Corinna Vinschen writes:
> > 
> >     > Hi,
> >     > I just uploaded a new setup-1.7.exe to install Cygwin 1.7.
> > 
> > 
> > vzell@xp /
> > $ ls -lt
> > ls: reading directory .: Bad address
> 
> Is that just an accident or are you trying to tell me something else
> with this mail?  Where's the message?

Fixed in CVS btw.  I'll upload a 1.7.0-28 release shortly...


Corinna

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

Re: New Setup for Cygwin 1.7 on cygwin.com

[Dr. Volker Zell]

>>>>> Corinna Vinschen writes:

    > On Aug 15 13:46, Dr. Volker Zell wrote:
    >> >>>>> Corinna Vinschen writes:
    >> 
    >> > Hi,
    >> > I just uploaded a new setup-1.7.exe to install Cygwin 1.7.
    >> 
    >> 
    >> vzell@xp /
    >> $ ls -lt
    >> ls: reading directory .: Bad address

    > Is that just an accident or are you trying to tell me something else
    > with this mail?  Where's the message?

It was inline in the dir listing:

drwxr-xr-x+ 1 vzell Users    0 Aug 15 10:41 cygdrive             <-- Is this directory really needed

Ciao
  Volker
  

Re: New Setup for Cygwin 1.7 on cygwin.com

[Corinna Vinschen]

On Aug 15 15:57, Dr. Volker Zell wrote:
> >>>>> Corinna Vinschen writes:
> 
>     > On Aug 15 13:46, Dr. Volker Zell wrote:
>     >> >>>>> Corinna Vinschen writes:
>     >> 
>     >> > Hi,
>     >> > I just uploaded a new setup-1.7.exe to install Cygwin 1.7.
>     >> 
>     >> 
>     >> vzell@xp /
>     >> $ ls -lt
>     >> ls: reading directory .: Bad address
> 
>     > Is that just an accident or are you trying to tell me something else
>     > with this mail?  Where's the message?
> 
> It was inline in the dir listing:
> 
> drwxr-xr-x+ 1 vzell Users    0 Aug 15 10:41 cygdrive             <-- Is this directory really needed

I didn't see that.  I also don't know what creates the /cygdrive dir.
My base-cygwin postinstall script certainly doesn't.


Corinna

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

Re: New Setup for Cygwin 1.7 on cygwin.com

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Corinna Vinschen on 8/13/2008 4:20 AM:
> Hi,
> 
> I just uploaded a new setup-1.7.exe to install Cygwin 1.7.
> 
> You can find it here:  http://cygwin.com/setup-1.7.exe 

Any reason this version insists on maximizing itself when going to the
package selection screen, rather than remaining at the size of the
previous screen?

- --
Don't work too hard, make some time for fun as well!

Eric Blake             ebb9@byu.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkil17kACgkQ84KuGfSFAYDTggCfXQKYt/+I1ujRtT6Hf9Pwdpk1
hoUAoJlSSJTltdaJf9JNEzq4y+hdz6ns
=m257
-----END PGP SIGNATURE-----

Re: New Setup for Cygwin 1.7 on cygwin.com

[Yaakov (Cygwin Ports)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Eric Blake wrote:
| Any reason this version insists on maximizing itself when going to the
| package selection screen, rather than remaining at the size of the
| previous screen?

Because someone programmed it that way. :-)

For the record, while it caught me by surprise the first time, I
actually like it.  Perhaps it should be part of the release
announcements though as a new feature.


Yaakov
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEAREIAAYFAkil2e0ACgkQpiWmPGlmQSPuzACgg19xzfRjgNrLjoxZXoUEyF/u
MGwAnRSMM3dXvVauMguhEZcS3EnkR5JH
=RzWG
-----END PGP SIGNATURE-----

Re: New Setup for Cygwin 1.7 on cygwin.com

[Christopher Faylor]

On Fri, Aug 15, 2008 at 01:23:38PM -0600, Eric Blake wrote:
>According to Corinna Vinschen on 8/13/2008 4:20 AM:
>> Hi,
>> 
>> I just uploaded a new setup-1.7.exe to install Cygwin 1.7.
>> 
>> You can find it here:  http://cygwin.com/setup-1.7.exe 
>
>Any reason this version insists on maximizing itself when going to the
>package selection screen, rather than remaining at the size of the
>previous screen?

Yep.  It's a feature designed to allow you to see all of the package
information.  I prefer this to manual resizing from the 640x480 size
every time.  Of course, you can always just click on the button in the
upper right corner of the screen if it bothers you.

I played around with just making all of the screens 1024x768 but I no
longer have a graphical way of handling dialog boxes and moving controls
around on the dialog boxes turned out to be quite tedious.  Since we're
using a property sheet there doesn't seem to be any easy way to make one
screen larger than the ones that preceded it.

My internal cygwin mailing list simulator also convinced me that there
would be an eventual complaint from someone with a small screen so it
seemed like maximizing this screen was the best compromise as it is
really the only screen that suffers from a small size, unless you want
to type in a really long path for your cygwin root.

The other change that I made was to have setup.exe check for last-*
(last-action, last-cache, etc.) information first from the download
directory and then from the etc directory.  Checking the closest
directory first seems to make more sense and I need this for another
project that I'm working on.  I hope that no one would actually notice
this change.  My internal simulator hasn't set off any alarms but
I guess we'll see.

cgf

RE: New Setup for Cygwin 1.7 on cygwin.com

[Dave Korn]

Christopher Faylor wrote on 15 August 2008 20:37:

> On Fri, Aug 15, 2008 at 01:23:38PM -0600, Eric Blake wrote:
>> According to Corinna Vinschen on 8/13/2008 4:20 AM:
>>> Hi,
>>> 
>>> I just uploaded a new setup-1.7.exe to install Cygwin 1.7.
>>> 
>>> You can find it here:  http://cygwin.com/setup-1.7.exe
>> 
>> Any reason this version insists on maximizing itself when going to the
>> package selection screen, rather than remaining at the size of the
>> previous screen?
> 
> Yep.  It's a feature designed to allow you to see all of the package
> information.  I prefer this to manual resizing from the 640x480 size
> every time.  Of course, you can always just click on the button in the
> upper right corner of the screen if it bothers you.

  I meant to bring this up when I noticed it.

  :-(  It's hideous.  It's a violation of good UI principles.  Windows that
do things like resizing themselves or changing depth order or stealing the
focus without an explicit instruction from the user to do so are obnoxious.
If a user has a lot of mirror subdirs in their local cache, parsing many
setup.inis can take a significant time, and they may have switched to
another application; when it suddenly jumps up in size, they aren't
expecting it and may easily find themselves pressing a button they hadn't
inte  AARGH I'M BLIND IT JUST LEAPT IN FRONT OF ME BUT DIDN'T TAKE THE FOCUS
WHERE AM I WHAT'S GOING ON!?!?! 

  Sorry about that.  Setup.exe just leapt to the front of the sort order and
maximized itself, completely obscuring the window in which I was typing this
email, although it didn't take the focus and I had no idea what was going on
for a moment.  It had been quietly sitting away in the background chundering
away to itself while I was typing, and then WHAM!  It's all like "HEY
EVERYBODY LOOK AT ME NO ME ME MEMEME MEEEEEE!".

  Can you tell I don't like it?  ;-)

  Seriously: why don't we just have it remember the user's last setting?
Like just about every other window in just about every other application
does?

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

New Setup for Cygwin 1.7 on cygwin.com

[Corinna Vinschen]

Hi,

I just uploaded a(nother) new setup-1.7.exe to install Cygwin 1.7.

You can find it here:  http://cygwin.com/setup-1.7.exe 

The version number is 2.606.
The SHA1 checksum is 2df4b76fbff6a1279aecdac342de67d291175560

New features:

- Now additionally reads /etc/fstab if it can find it.

Features already in 2.605:

- Installs 1.7 on NT and 1.5.x on 9x.

As far as NT is affected:

- Uses long path names and the Cygwin UNICODE transformation of special
  DOS characters.  This should allow to install files with special DOS
  chars (foo:bar, a<b), as well as files with names consisting of DOS
  device names (nul.exe, aux.c).

- Setup will still look for an old install by searching the 1.5.x
  registry mount points.  If you don't change to another dir in the
  "Choose Installation Directory" dialog, it will perform an upgrade
  rather than a fresh parallel install.  So, please change the root
  directory to something like, say, C:\cygwin-1.7

- Reads package DB the first time *after* the user pressed the "Next"
  button in the "Choose Installation Directory" dialog, so that setup
  doesn't use the package DB from a former installation by accident if
  the user chooses to install into a new directory.
  
  This only works once! 
  
  If you press the "Next" button in the "Choose Installation Directory"
  dialog before you changed the root directory, then press the "Back"
  button, it's too late.  In that case, press "Cancel" and restart
  Setup-1.7.
  
  I couldn't figure out how to drop the entire package DB in memory so
  that it can be re-read when the directory gets changed by the user.
  Can somebody help coding this?

- Does not write registry mount points anymore.

- Dynamically changes the layout of the "Choose Installation Directory"
  dialog so that there's no user choice for text/binmode.

Other changes:

- Silently skip empty tar packages of the 46 byte type (for instance
  gcc-3.4.4-3).

- New command-line option which was already present in Dave's test
  release 2.602:
  
  -P --packages                          Specify packages to install

Perhaps I screwed something up with my patches which worked before,
but it worked fine for me, so I don't know.  Please give it a try
and report back.


Have fun,
Corinna




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

Re: New Setup for Cygwin 1.7 on cygwin.com

[Yaakov (Cygwin Ports)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Corinna Vinschen wrote:
| Perhaps I screwed something up with my patches which worked before,
| but it worked fine for me, so I don't know.  Please give it a try
| and report back.

Thanks!

I haven't tested it extensively, but I was able to successfully install
a brand new 1.7 system (just Base and a few devel tools so far)
alongside my existing 1.5.  Now all we need is the new gcc, and the
long-awaited rebuild can begin.

I noticed one minor thing, which I'm not sure if it's a bug or feature:
~ whatever created the default /etc/fstab similar to the 1.5 mount points
in the registry also made mount points for 1.5 managed mounts.  These
were useless to me as I was creating a brand new install, so I removed
them.  But would they be necessary even if someone was upgrading in the
same root?  If not, perhaps they should be ignored when creating the
initial /etc/fstab?


Yaakov
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEAREIAAYFAkilEJIACgkQpiWmPGlmQSPE3wCffTRCb8AndTN+VDkVs4KfhuSf
NngAnRK5X3Ec5YEq6rFRLS5G5LbkeA3E
=GvRo
-----END PGP SIGNATURE-----

Re: New Setup for Cygwin 1.7 on cygwin.com

[Corinna Vinschen]

On Aug 15 00:13, Yaakov (Cygwin Ports) wrote:
> I noticed one minor thing, which I'm not sure if it's a bug or feature:
> ~ whatever created the default /etc/fstab similar to the 1.5 mount points
> in the registry also made mount points for 1.5 managed mounts.  These
> were useless to me as I was creating a brand new install, so I removed
> them.  But would they be necessary even if someone was upgrading in the
> same root?  If not, perhaps they should be ignored when creating the
> initial /etc/fstab?

That makes sense.  I'm going to tweak the postinstall script accordingly.

While I'm at it, I found that the default %Path% variable does not use
the right case for the Windows and Windows/system32 paths on some
versions of Windows.  The result is that tools like Window's ping are
not found when case sensitivity is switched on, unless you tweak the
system %Path% variable to us the right case throughout.

So, here's the question: 

Shall the script make the cygdrive prefix a posix=0 (aka case-insensitve)
mount by default?


Corinna

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

Re: New Setup for Cygwin 1.7 on cygwin.com

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Corinna Vinschen on 8/15/2008 5:41 AM:
> So, here's the question: 
> 
> Shall the script make the cygdrive prefix a posix=0 (aka case-insensitve)
> mount by default?

Sounds good to me.  Case sensitivity is only reliable inside an
environment that is expecting it (ie. cygwin files deserve it, but we
can't expect the rest of windows to be ready for it).

- --
Don't work too hard, make some time for fun as well!

Eric Blake             ebb9@byu.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkilb1IACgkQ84KuGfSFAYD24wCfafdh0tDJ28ljcI0HLomCCB/L
yzkAnRu8aBHsYMCNR/42h73YtRuuoFb1
=7bkM
-----END PGP SIGNATURE-----

Re: New Setup for Cygwin 1.7 on cygwin.com

[Corinna Vinschen]

On Aug 15 05:58, Eric Blake wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> According to Corinna Vinschen on 8/15/2008 5:41 AM:
> > So, here's the question: 
> > 
> > Shall the script make the cygdrive prefix a posix=0 (aka case-insensitve)
> > mount by default?
> 
> Sounds good to me.  Case sensitivity is only reliable inside an
> environment that is expecting it (ie. cygwin files deserve it, but we
> can't expect the rest of windows to be ready for it).

Ok, I uploaded a new base-cygwin package which skips managed mounts
and sets the cygdrive prefix to posix=0 by default.  Same for the
Cygwin DLL.


Corinna

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

Re: New Setup for Cygwin 1.7 on cygwin.com

[Charles Wilson]

Corinna Vinschen wrote:

> I just uploaded a(nother) new setup-1.7.exe to install Cygwin 1.7.
> 
> You can find it here:  http://cygwin.com/setup-1.7.exe 
> 
> The version number is 2.606.
> The SHA1 checksum is 2df4b76fbff6a1279aecdac342de67d291175560

So, I used this new setup to *update* my existing side-by-side
cygwin-1.7 installation, which was originally created using an older
(setup-2.588) version of setup-1.7.

Notes:

1) warning message:

Unable to extract /etc/alternatives/.keep-alternatives -- the file is in
use. Please stop all cygwin processes and select "Retry",, or select
"Continue" to go on anyway (you will need to reboot).

Odd. I already *did* stop all cygwin processes -- and besides, what
could possibly be uses .keep-alternatives?

Anyway, I selected Continue.

No good -- now it's stuck -- on /etc/alternatives/.keep-alternatives  --
using about 50% CPU, forever.

Repeats over and over:

Installing file cygfile:///etc/alternatives/.keep-alternatives
2008/08/15 16:31:32 io_stream_cygfile:
fopen(/etc/alternatives/.keep-alternatives) failed 13 Permission denied
2008/08/15 16:31:32 Failed to open
cygfile:///etc/alternatives/.keep-alternatives for writing.
2008/08/15 16:31:32 io_stream_cygfile:
fopen(/etc/alternatives/.keep-alternatives.new) failed 13 Permission denied
2008/08/15 16:31:32 Failed to open
cygfile:///etc/alternatives/.keep-alternatives.new for writing.
2008/08/15 16:31:32 Unable to install file
cygfile:///etc/alternatives/.keep-alternatives.new

Here's the wierd part: -- there is no .keep-alternatives file in
cygwin-1.7/etc/alternatives.

(I canceled, but now my 1.7 installation is completely scrogged, since
setup-1.7 DID manage to download everything it needed, uninstall the
to-be-upgraded items, and then hang while unpacking one of them.

So, no bash, no cygwin1.dll...

2) So, I re-ran setup-1.7, this time "from local directory" so I could
make sure all the stuff that got downloaded the last time actually would
get installed.  No joy -- hung at the same place.

A little more investigating shows that:

1) /var, /tmp, /etc, and /home have very odd security settings
Administrators have Read&Excecute,Read,List,Write
Administrator has no access
Users have no access
SYSTEM has Read&Execute,Read,List,Write
No entry for CREATOR OWNER or CREATOR GROUP

OTOH, /etc/alternatives has similar settings, except it DOES have
entries for CREATOR OWNER and CREATOR GROUP -- which provide no access.

2) /bin, /lib, all inherit their security settings from the parent
directory C:\cygwin-1.7

I think the problem here is that I had to jump through some hoops with
regards to permissions *pre-installation* back when I originally
installed cygwin-1.7 (see http://cygwin.com/ml/cygwin/2008-04/msg00392.html)

I tried adding explicit 'Full Control' to /etc for 'Administrator' but
that didn't help either.

I think I'm fubared.  This is SO messed up.

Vista + UAC + cygwin seems a bit...flaky.

--
Chuck

Re: New Setup for Cygwin 1.7 on cygwin.com

[Charles Wilson]

Charles Wilson wrote:
> 
> Vista + UAC + cygwin seems a bit...flaky.

Yep.

I moved my old cygwin-1.7 installation and reinstalled. This time, I did
nothing special -- I did /not/ prepare the C:\cygwin-1.7 directory in
advance (e.g. create the directory and then edit its security settings).

This is on Vista, with UAC enabled.

I ran setup-1.7 as Administrator (while logged in to my normal user
account, which is not a member of the Administrators group). I got the
privilege elevation prompt, and typed in the password.

The installation seemed to go fine.

However, when I launched cygwin as my normal self, I got some errors
from my .bashrc:

bash: cannot create temp file for here document: Permission denied
rm: cannot remove `/c/Users/self/.keychain/mymachine-lockf': Permission
denied

Here are some relevant perms:

$ ls -l /
total 526K
----r-x---+  1 Administrator Users      61 Aug 15 17:16 Cygwin.bat*
----r-x---+  1 Administrator Users    6.9K Aug 15 18:11 Cygwin.ico*
d---r-x---+  1 Administrator Users    384K Aug 15 17:55 bin/
d---------+  1 ????????      ????????  20K Aug 15 17:14 c/
d--x--x--x   4 self          None        0 Nov 30  2006 cygdrive/
drwxr-xr-x+  1 self          None      16K Aug 15 16:14 desktop/
drwxrwxr-x+  1 Administrator Users       0 Aug 15 17:16 dev/
drwxrwxr-x+  1 Administrator Users    8.0K Aug 15 17:55 etc/
d---r-x---+  1 Administrator Users     80K Aug 15 17:55 lib/
drwx------+  1 self          None     4.0K May 24 00:20 mydocs/
dr-xr-xr-x  12 self          None        0 Nov 30  2006 proc/
d---r-x---+  1 Administrator Users       0 Aug 15 17:52 sbin/
lrwxrwxrwx   1 Administrator Users      17 Aug 15 17:16 terminfo ->
../share/terminfo
drwxrwxrwt+  1 Administrator Users       0 Aug 15 18:13 tmp/
d---r-x---+  1 Administrator Users    4.0K Aug 15 17:54 usr/
d---r-x---+  1 Administrator Users       0 Aug 15 17:16 var/

(the terminfo symlink is, I think, because the terminfo postinstall
script is running before the fstab is created, but that's just a guess,
and isn't what I'm concerned about here)

$ ls -l /etc
total 541K
-rw-rw-rw-  1 Administrator Users 4.4K Aug 15 17:16 DIR_COLORS
d---r-x---+ 1 Administrator Users 4.0K Aug 15 17:53 X11/
d---r-x---+ 1 Administrator Users 4.0K Aug 15 17:55 alternatives/
-rw-rw-rw-  1 Administrator None   301 Aug 15 17:16 bash.bashrc
-r-xr-x---  1 Administrator None   844 Aug 15 17:54 colordiffrc*
drwxr-xr-x+ 1 Administrator None     0 Aug 15 17:54 colorgcc/
-r-xr-x---  1 Administrator None  1.5K Aug 15 17:54 cygport.conf*
d---r-x---+ 1 Administrator Users    0 Aug 15 17:15 defaults/
-r-xr-x---  1 Administrator None  4.8K Aug 15 17:54 enscript.cfg*
d---r-x---+ 1 Administrator Users    0 Aug 15 17:50 fonts/
-rw-rw-rw-  1 Administrator None  3.3K Aug 15 17:16 fstab
drwxrwxrwt+ 1 Administrator None     0 Aug 15 18:13 fstab.d/
-rw-r--r--+ 1 Administrator None    14 Aug 15 17:25 ftpusers
-rw-r--r--+ 1 Administrator None    40 Aug 15 17:25 ftpwelcome
-rwxrwxrwx  1 Administrator Users  457 Aug 15 17:16 group*
drwxrwxrwx+ 1 Administrator None     0 Aug 15 17:54 gtk-2.0/
lrwxrwxrwx  1 Administrator None    37 Aug 15 17:16 hosts ->
/c/Windows/system32/drivers/etc/hosts*
-r-xr-x---  1 Administrator None   422 Aug 15 17:25 hosts.allow*
-r-xr-x---  1 Administrator None   225 Aug 15 17:25 hosts.deny*
-rw-r--r--+ 1 Administrator None  2.5K Aug 15 17:25 inetd.conf
drwxrwxr-x+ 1 Administrator Users    0 Aug 15 17:24 inetd.d/
-r-xr-x---  1 Administrator None  1.7K Aug 15 17:54 inittab*
-r-xr-x---  1 Administrator None  137K Aug 15 17:55 lynx.cfg*
----r-x---+ 1 Administrator Users 123K Jul 22 11:49 moduli*
-rw-r--r--+ 1 Administrator None  1.7K Aug 15 17:25 motd
lrwxrwxrwx  1 Administrator None    40 Aug 15 17:16 networks ->
/c/Windows/system32/drivers/etc/networks*
drwxrwxrwx+ 1 Administrator Users    0 Aug 15 17:54 pango/
-rwxrwxrwx  1 Administrator Users 1.3K Aug 15 17:16 passwd*
d---r-x---+ 1 Administrator Users  28K Aug 15 17:55 postinstall/
d---r-x---+ 1 Administrator Users  12K Aug 15 17:54 preremove/
-rw-rw-rw-  1 Administrator None  6.4K Aug 15 17:16 profile
d---r-x---+ 1 Administrator Users 4.0K Aug 15 17:53 profile.d/
lrwxrwxrwx  1 Administrator None    40 Aug 15 17:16 protocols ->
/c/Windows/system32/drivers/etc/protocol*
d---r-x---+ 1 Administrator Users 4.0K Aug 15 17:54 rc.d/
lrwxrwxrwx  1 Administrator None    40 Aug 15 17:16 services ->
/c/Windows/system32/drivers/etc/services*
d---r-x---+ 1 Administrator Users 128K Aug 15 17:53 setup/
-rw-r--r--+ 1 Administrator None   138 Aug 15 17:25 shells
d---r-x---+ 1 Administrator Users    0 Aug 15 17:16 skel/
d---r-x---+ 1 Administrator Users    0 Aug 15 17:52 ssmtp/
d---r-x---+ 1 Administrator Users    0 Aug 15 17:54 sysconfig/
-rw-r--r--+ 1 Administrator None   368 Aug 15 17:25 syslog.conf
----r-x---+ 1 Administrator Users  15K Aug 15 17:55 termcap*
d---r-x---+ 1 Administrator Users    0 Aug 15 17:52 terminfo/
----r-x---+ 1 Administrator Users 4.2K Jun  4 12:32 wgetrc*
-rwxr-xr-x  1 Administrator None   298 Nov 10  2002 xinetd.conf*
drwxr-xr-x+ 1 Administrator None  4.0K Nov  9  2002 xinetd.d/

$ (cd ~/.. && ls -ld *)
drwxr-xr-x+ 1 SYSTEM         SYSTEM    12K Jul 22 22:55 Administrator/
lrwxrwxrwx  1 SYSTEM         SYSTEM     23 Nov  2  2006 All Users ->
/cygdrive/c/ProgramData/
drwxr-xr-x+ 1 Administrators ???????? 8.0K Nov  2  2006 Default/
lrwxrwxrwx  1 SYSTEM         SYSTEM     25 Nov  2  2006 Default User ->
/cygdrive/c/Users/Default/
drwxr-xr-x  1 self           None        0 Apr 26 21:43 HP_Admin/
drwx------+ 1 Administrators ???????? 4.0K Mar 18 14:31 Public/
drwxr-xr-x+ 1 SYSTEM         SYSTEM    16K Aug  7 19:45 self   /
drwxr-xr-x  1 self           None        0 Apr 25 14:51 cyg_server/
-rwxr-xr-x+ 1 SYSTEM         SYSTEM    174 May 24 14:51 desktop.ini*

(I have no idea why self owns the HP_Admin and cyg_server home
directories. That's just bizarre).

$ getfacl ~
# file: /c/Users/self
# owner: SYSTEM
# group: SYSTEM
user::rwx
user:self:rwx
group::rwx
group:root:rwx
mask:rwx
other:r-x
default:user:self:rwx
default:group:root:rwx
default:group:SYSTEM:rwx
default:mask:rwx

$ getfacl /tmp
# file: /tmp
# owner: Administrator
# group: Users
user::rwx
group::rwx
group:root:rwx
group:SYSTEM:rwx
mask:rwx
other:rwx
default:group:root:rwx
default:group:SYSTEM:rwx
default:group:Users:r-x
default:mask:rwx

None of this seems right. The Users group does not have write access to
/tmp, for one thing. SYSTEM owns my home directory, even if I do have an
 rwx ACL entry. And the perm bits on everything just look /wrong/.

I think setup.exe on Vista should be a little more careful about the
permissinos/ownership it applies to files and directories that it
creates, especially under the installation scenario above -- which ought
to be considered the, or one of a very few, "normal" installation
scenario(s) on Vista.

I do NOT think users should be expected to FIRST create their
installation directory manually, then muck about with its inheritable
security settings, before running setup-1.7.exe for the first time for a
"virgin" install. (that's what I had to do last time, with setup-2.588)

--
Chuck