Re: Requirements depth in setup.exe

[Brian Dessent <brian at dessent dot net>]

"Thrall, Bryan" wrote:

> We have a custom cygwin mirror for distributing our software and
> occasionally run into problems where a package that is listed in the
> setup.ini as being required isn't installed like it should be. For
> example, xterm is required (eventually) but isn't installed by default.
> The problem seems to be a limitation in setup.exe:
> packageversion::set_requirements() has a hardcoded recursion depth of 5,
> and as best I can tell, xterm for our purposes has a depth of 6.
> Increasing the limit to 20 allowed xterm to be set to install like it
> should be.

For the record, as of right now the longest dep chains[1] in setup.ini
top out at 12:

octave-htmldoc -> octave-doc -> octave -> gnuplot -> xorg-x11-bin-dlls
-> xorg-x11-base -> xorg-x11-libs-data -> tar -> bzip2 -> coreutils ->
tzcode -> gawk

octave-headers -> octave-devel -> octave -> gnuplot -> xorg-x11-bin-dlls
-> xorg-x11-base -> xorg-x11-libs-data -> tar -> bzip2 -> coreutils ->
tzcode -> gawk

There are many more at lesser lengths that are still greater than 5, so
it's clear that 5 is too small.

However, I'm concerned that this patch touches a lot more than just a
recursion/looping safety valve.  It seems like you're duplicating the
existing functionality of the 'visited' flag in a very inefficient way
by maintaining that set.  I'm going to have to play with this some more
before I can come to a conclusion.

Brian

[1] I wrote a rather brute force perl script to compute this:
<http://dessent.net/tmp/cygpackage-longest-path.pl>.  The output takes a
while to compute and looks like
<http://dessent.net/tmp/cygpackage-dep-chains.txt>.