Mailing-List: contact cygwin-apps-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-apps-owner AT cygwin DOT com
List-Subscribe: <mailto:cygwin-apps-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-apps/>
List-Post: <mailto:cygwin-apps AT cygwin DOT com>
List-Help: <mailto:cygwin-apps-help AT cygwin DOT com>, <http://sources.redhat.com/lists.html#faqs>
Delivered-To: mailing list cygwin-apps AT cygwin DOT com
Date: Tue, 19 Feb 2002 11:53:13 EST
To: cygwin-apps AT cygwin DOT com
Subject: Re: Setup
X-Mailer: Virtual Access by Atlantic Coast PLC, http://www.atlantic-coast.com/va
Message-Id: <VA.00000a89.007b61b0@thesoftwaresource.com>
From: Brian Keener <bkeener AT thesoftwaresource DOT com>
Reply-To: bkeener AT thesoftwaresource DOT com
In-Reply-To: <00af01c1b901$11ab0110$0200a8c0@lifelesswks>
References: <015a01c1b886$622561b0$0200a8c0 AT lifelesswks> <VA DOT 00000a82 DOT 00e1d48b AT thesoftwaresource DOT com> <002501c1b8e4$9754b5d0$0200a8c0 AT lifelesswks> <20020219040513 DOT GA372 AT redhat DOT com> <009701c1b8fc$a8eedba0$0200a8c0 AT lifelesswks> <VA DOT 00000a86 DOT 0036ae18 AT thesoftwaresource DOT com> <00a501c1b8fe$de081480$0200a8c0 AT lifelesswks> <VA DOT 00000a87 DOT 00429279 AT thesoftwaresource DOT com> <00af01c1b901$11ab0110$0200a8c0 AT lifelesswks>

Robert Collins wrote:
> > That's where our view differs because I see the radio buttons as a way
> of
> > selecting the maximum version I want considered and if that version
> does not
> > exist then the default is the next version down (Test -> Current ->
> Prev
> > depending on Radio button selected) and if the version selected is
> what is
> > installed the default is keep and if it is not installed at all then
> the
> > default is skip.
> 
> Well, I'll consider a patch to setup to change it's behaviour. At the
> moment no limitation of maximum version is present, regardless of the
> prev/curr/test state.

I catch the drift on the patches and the same with the other two we discussed.  
At one point in time when I was still submitting changes to setup, when I still 
understood the code before the major rewrite :-) - don't get me wrong this is 
good stuff - I thought we had it where Test, Curr, and Prev only set the 
maximum version we wanted to look at.  But on the down side we never had it 
fully functional where it would handle multiple versions simply because they 
existed on disk and this is a very good new feature.  I would not want to loose 
itt.

But what I do propose is that we think of Prev as the last stable version, we 
think of Current as the current stable and we think of test as a development 
version - which could be changing rapidly.  There may be any number of versions 
resident on my disk that are in between the control points and they should all 
be available for me to choose from in the chooser.  But the maintainer dictates 
via setup.ini which version is the Prev stable, Curr stable and experimental 
(Test) or any combination thereof. 

With this in mind the Prev, Curr, and Test buttons should simply set the 
maximum version (with the primary choice being the Current Stable for the 
inexperience that simply want to use the product) that I want installed of any 
given package and then I still have the ability to select any other major or 
intermediate version (these amy or may not be a Prev, Curr, or Test) for a 
package as well.  Essentially if I have the Current radio selected and a Prev 
is installed and there is a new Curr it will select that current version for 
install and if on another package I have a Test version installed and there is 
a Curr version available then it will select the current version for install 
(thus deinstalling the Test version) and if by some quirk I have a Test 
installed, the Current Radio button selected but there is no Curr version it 
will select the Prev and if there is no Prev version it will simply select keep 
(although I'm not sure I like this - but I like an uninstall option even less).

I would think we also need some mechanism (because of the ability to mix and 
match versions) to give the user the ability to select the default actions for 
all packages listed - for example: 1) I want to *keep/skip* (depending on if 
installed or not) all and then simply upgrade one or two - no matter what is 
available 2) I want to *reinstall* whatever I currently have installed - no 
matter what is available 3) I want to install *sources* for everything I have 
installed - nothing more - nothing less and the really nasty option I want to 
*uninstall* everything with a big fat warning.  I am essentially describing a 
global for the chooser that lets me pick from the standard chooser options but 
for all packages.  I can then pick and choose below that for the individual 
package.  I am sure categories will to some degree get in the way of this but I 
am sure that some workable solution could be found.

Another nice touch and clarification in chooser might be to expand the text on 
the version number in the display for those packages where I might have 5 
versions available for install.  As I am clicking through the versions on a 
given package when I get to a version that is the Prev, Curr or Test if the 
text shows this - ie 1.4.5 (Curr) or 1.4.3 (Prev) or 1.4.4.  In this case 1.4.4 
is just an available intermediate.

This is my $.02 worth and the world of setup and chooser as I see and would 
code if I could - don't get me wrong I'm still trying but the going is slow - 
got my hands in too many pots (and some have hot water) and setup is a tough 
teacher for learning C++.

Bk