Robert Collins wrote: >>the name change >>itself is necessary and significant. >> > > Right. But the one package could provide the same .dll twice (until all > dependent packages are rebuilt).
I'd prefer not to complicate the "libfooX" package by starting down the path where "libfoo1" contains both cygfoo-1.dll and cygfoo.dll. I'd rather insure that libfooX contains only cygfoo-X.dll -- and put cygfoo.dll into libfoo0 or just plain libfoo. >>>Why? If gettext needs libintl1, and sharutils et al need libintl0, >>> > then > >>>anyone who updates will get libintl0 automatically if they have >>>sharutils et al installed. >>> >>Hmm...I want to test this first.... >> > > Go right ahead :]. Tweak a setup.ini locally, and install from there. > Recursion works. Yeah, I know I can test this -- but I couldn't at the time I wrote the other message. (was traveling). Anyway, I just tested and *yes*: given a system that had wget installed "long ago" when it depeded on 'gettext' gettext (old pre-split version) I changed the setup.hint for 'wget' to now depend on libintl0 And then ran 'upset/setup' in my sandbox with new modified wget/setup.hint (NOW depends on libintl0) libintl0 (depends on nothing relevant here) libintl1 (depends on nothing relevant here) gettext (depends on libintl1) setup automatically determined that I needed to: a) update gettext from 0.10.38-2 to 0.10.40-1 b) install the "new" libintl0-0.10.38-3 package c) install the new libintl1-0.10.40-1 package Since "g"ettext comes before "l"ibintl0, the uninstall/reinstall occured in the proper order, and I still had a working system. Unlike ncurses, alphabetization works for us here -- it would be bad if libintl0 was installed (replacing cygintl.dll with the "new" version), and THEN gettext was uninstalled (removing cygintl.dll) followed by installing the new gettext (which contains no cygintl.dll). I don't know how to deal with the problem above -- which occurs if the package being split (ncurses, readline, gettext) follows rather than precedes 'l'ibXXXX in the alphabet...but we can deal with that when/as it occurs. (Perhaps upgrades of currently installed packages should ALWAYS precede installation of new packages?) --Chuck
