Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
content-class: urn:content-classes:message
Subject: RE: Bug in setup.exe 2.194.2.24
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Date: Mon, 22 Apr 2002 21:36:46 +1000
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Message-ID: <FC169E059D1A0442A04C40F86D9BA7600C5EC1@itdomain003.itdomain.net.au>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To: "Cliff Hones" <cliff AT aonix DOT co DOT uk>, <cygwin AT cygwin DOT com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id g3MBbgx12144



> -----Original Message-----
> From: Cliff Hones [mailto:cliff AT aonix DOT co DOT uk] 
> Sent: Monday, April 22, 2002 9:14 PM
 
> The problem seems to be that setup doesn't set these 
> already-present packages to 'keep' or 'skip' by default, and 
> there's no way for the user to find out which packages are in 
> this state.

So you are suggesting that in download mode it should not offer to
upgrade any installed packages by default? Or that it should only offer
upgrades for installed packages without cached files?

I'll happily accept a (reasonable) patch for the second case, but the
first case also seems counter-intuitive to me.
 
> I can't actually see any advantage in re-downloading the 
> packages *by default*.  

The point of 'download' mode is to allow downloads. If you choose not to
install what you have downloaded, what should setup assume that means?

> This is very unhelpful if one download failed to complete, 
> and you just want to re-fetch what hadn't been transferred on 
> the previous run.

There is a lot that setup does that needs to be more persistent. It
needs the ability to hold packages (ie 'do not offer to upgrade
autoconf'), and much more.
 
> Also, does the current implementation 
> mean that I won't be informed of a newly-added package by default?

Yes.
 
> And even cgf and the implementors now seem undecided as 
> to what should be happening.  

You do realise that that includes me I hope :}.

> So can I ask for 
> the design decision to be re-addressed?  I'd like to hear 
> what the arguments in favour of the current mechanism are.

I'd like to remove the re-download facility completely. If a package
file is corrupt, delete the local copy and then run setup. This makes
setup simpler, for little cost. Setup won't keep partial files anyway,
so the only form of corruption has to be network transit problems, and
GPG signing would solve that too, and allow setup to detect and remove
corrupt packages automatically.

Rob

--
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/