This is the mail archive of the cygwin-apps mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Requirements depth in setup.exe


Sorry for the top posting but could we get closure on the issues discussed
below?  It seems like this problem could be impacting a lot of people and
this is a bug that really needs to be fixed.

I'm going to raise the recursion check from 5 to 30 but I am not sure that
this will actually have a beneficial effect.

cgf

On Fri, Jun 27, 2008 at 05:26:27PM -0500, Thrall, Bryan wrote:
>Brian Dessent wrote on Friday, June 27, 2008 4:46 PM:
>
>> "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.
>
>Hmmm... my own brute force perl script found a maximum depth of 14, but
>we mostly agree :) Probably mine has a bug somewhere; I'm very new with
>Perl.
>
>> 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.
>
>It seemed like purpose of the visited flag overlapped, but I wasn't
>familiar enough with the code to say it was equivalent.
>
>Perhaps the (depth > 5) check in packageversion::set_requirements()
>isn't needed at all?
>
>-- 
>Bryan Thrall
>FlightSafety International
>bryan.thrall@flightsafety.com
>
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]