Should setup suggests to downgrade? [WAS: Lillypond for cygwin]

Cliff Hones cliff@aonix.co.uk
Sat Apr 6 06:06:00 GMT 2002


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.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: setup.log.full
Type: application/octet-stream
Size: 9125 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin/attachments/20020406/5b8934fa/attachment.obj>
-------------- next part --------------
--
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/


More information about the Cygwin mailing list