This is the mail archive of the cygwin@cygwin.com 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] |
From: "Robert Collins" <robert.collins@itdomain.com.au> Subject: RE: Should setup suggests to downgrade? [WAS: Lillypond for cygwin] > > From: Cliff Hones [mailto:cliff@aonix.co.uk] > > Sent: Saturday, April 06, 2002 7:03 PM > > > Never say never? Suppose a showstopper bug is found in a > > released package - say one which could result in filestore or > > configuration corruption. The quickest solution would be to > > revert to the previous version, and to make this painless > > (and avoid traffic here) having the downgrade done > > automatically by setup would be nice. > > That's the point of the 'test' marking. And that's why currently curr > overrides test even if test is a higher version number. I see - so a current version can be 'pulled' by moving it to test. And setup.exe always by default downgrades all test packages to current, unless 'Exp' is selected, when it by default upgrades all current packages to test. Ok, but this seems a little clumsy - it would be nicer if the selection of packages explicitly downloaded as test in the past could be remembered so it's not necessary to reselect them individually (or risk running all test versions, including 'pulled' ones). And if setup were extended to do this, it would have to work on the basis of which ones were installed using the setup.ini test section - not by seeing if the previously installed version was now in the test category. As I wasn't sure I understood how setup currently deals with test, I just tried it with autoconf-devel. This showed up what seems to be a bug. I didn't have the test version of autoconf-devel in my local install directory, but didn't realise this, so I ran 'install from local directory'. The Exp/partial view showed the test version of autoconf-devel. I returned to 'Curr', explicitly picked the test version of autoconf-devel, and started the install. But this failed - it uninstalled the old autoconf-devel, then couldn't find the new one. setup.log.full attached. This seems wrong - it shouldn't be offering to install a package which isn't present locally. Maybe something like this is what is happening to people who have reported that they needed to run setup several times to get everything installed right, and found some of the base packages were initially missing? [Though that's never happened to me.] Next I ran 'download from internet'. Because the previous install managed to uninstall autoconf-devel, it was now shown in the 'skip' state, even after I clicked on 'Exp', and I had to explicitly choose to download the test version. [It didn't even tell me I already have the current version of autoconf-devel available.] [I've already mentioned I'm not happy with the current download mode - I think it loses a lot of its potential power, and is also confusing, by being intertwined with the current install state. Indeed, I see little value in separating the download and install as currently implemented. Seeing no comment after my earlier mail, do I assume I'm either doing something wrong, or nobody else finds this a problem?] I hope you find these comments constructive. I do feel setup.exe is a great tool, though it still has a few rough edges. Cliff.
Attachment:
setup.log.full
Description: Binary data
-- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |