Just today I noticed a buglet in setup.exe where it will "lose" some dependencies when pressing the "curr" radio button, even if that is the current selected choice. That kind of violates the principle that selecting something that's already selected shouldn't have any effect.
Here's a very simple example that illustrates how bad it can be. Move your current cygwin setup away to a safe place (mount -m > mounts.bat; umount -A; ren \cygwin \cygwin-old) and run setup. Change absolutely nothing, i.e. take all the defaults. You should get the standard base system which currently consists of:
ash base-files base-passwd bash bzip2 coreutils cygutils cygwin cygwin-doc diffutils editrights findutils gawk gdbm grep groff gzip less libbz2_1 libcharset1 libgdbm libgdbm-devel libgdbm3 libgdbm4 libiconv libiconv2 libintl libintl1 libintl2 libintl3 libncurses5 libncurses6 libncurses7 libncurses8 libpcre libpcre0 libpopt0 libreadline4 libreadline5 libreadline6 login man mktemp ncurses readline sed tar termcap terminfo texinfo which zlib _update-info-dir
Okay, fair enough. Now blow away that installation and try again. This time do the same thing, accept all the defaults, BUT click on "curr" even though that radio button is already selected, and press Next. Setup helpfully removes a bunch of critical packages. You get the above list of packages MINUS (!!) the following:
groff less libz2_1 libcharset1 libiconv libintl libintl1 libintl3 libpcre libpcre0, libpopt0 mktemp
Needless to say you get a real headache when it comes to try to run the postinstall scripts, particularly the missing cygintl-3.dll and cygpopt-0.dll. In this example you get about three dozen popup "missing DLL" errors. If you run setup a second time and accept setup's choices you will see the above list of packages in the "partial" view as setup finds and selects all the missing stuff.
It seems that what's happening is that when you press "curr" setup tries to reselect the current version of every package, but in doing so it misses some things, and since they were not installed before (since *nothing* was installed before) they get deselected. I haven't looked at the setup code all that thoroughly but if I recall correctly there's a hard-coded limit of 5 levels of recursion in there to prevent looping. Perhaps the dependency tree for a system with no current packages installed is deep enough that setup is hitting that and stopping early. I don't really know. But it would explain a lot of the support emails that basically amount to "I have this error saying missing cygfoo.dll!" where cygfoo.dll is some dependent lib that setup should have installed but didn't. I always thought it was people deselecting things they thought they didn't need, but setup might be causing it if they clicked back and forth between curr/test a couple of times or something.
Wow!
Very useful info!
It may take me a while to comprehend the dependency code, but bugzilla-ed for now.
Max.
