Mailing-List: contact cygwin-apps-help AT cygwin DOT com; run by ezmlm Sender: cygwin-apps-owner AT cygwin DOT com List-Subscribe: List-Archive: List-Post: List-Help: , Delivered-To: mailing list cygwin-apps AT cygwin DOT com Message-ID: <009d01c1b8fe$40d7c110$0200a8c0@lifelesswks> From: "Robert Collins" To: , References: <015a01c1b886$622561b0$0200a8c0 AT lifelesswks> <002501c1b8e4$9754b5d0$0200a8c0 AT lifelesswks> Subject: Re: Setup Date: Tue, 19 Feb 2002 15:31:07 +1100 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 19 Feb 2002 04:30:21.0489 (UTC) FILETIME=[24650A10:01C1B8FE] === ----- Original Message ----- From: "Brian Keener" To: "Robert Collins" ; Sent: Tuesday, February 19, 2002 3:18 PM Subject: Re: Setup > Robert Collins wrote: > > I have emailed trying to start a discussion on this at least twice. My > > contention is that this is a factor for setup.ini to take care of, not > > setup.exe. It's easier to add entries than have complex logic for > > removing them when they aren't appropriate. > > > So what you're saying is just looking at Current vs Previous - if there was no > setup.ini entry for current and there was only an entry for previous then with > the default display set to current the selected default action for the > theoretical package would be uninstall (just as I saw on the Test) - correct? No. There is a pretty big difference (IMO) between prev, current and test. Prev - distribution with old versions kept around for convenience sake. Current - distribution with the latest stable versions. Test - distribution with versions where things break, major changes occur etc. Any version of a package can be selected without the use of the prev/curr/test buttons - they are designed to make wholesale changes to the environment. Prev-Current should be minor - to allow backing out of a minor revision change that introduced a new bug. Current-Test *may* be very major. we have currently in the 'default' picking logic: packageversion * trustp (trusts const t) const { return t == TRUST_PREV ? (prev ? prev : (curr ? curr : installed)) : t == TRUST_CURR ? (curr ? curr : installed) : exp; } IOW, for prev, choose an explicit prev, then a current, and then an installed. for current, choose a current, and then an installed. for test (exp), choose the explicit experimental version. > And in addition if as a maintainer I didn't want this to happen then I should > make sure I have a prev,curr and test in setup.ini even if they all are the > same file name. That is one way, it is very manual however. What I'm suggesting is that *in the absence* of prev:,curr:,test: tags in setup.hint, that upset always generate a [test] entry - just like it automatically generates a [prev] entry when there are two versions in the directory. > This bears the question (if my previous assumption is correct) what if my > setup.ini has a prev, curr, and test file defined but I am doing an "Install > from Local Directory" and the test version does not exist on my system. I > would assume that since I defined a test and even though is does not exist that > my default action would be keep - true? I'm not sure :}. I'm not sure that that would be appropriate behaivour in the general case. We really need versioned conflicts: and depends: lines to make this all work correctly. Rob