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
Message-ID: <0f6601c19574$7964f910$0200a8c0@lifelesswks>
From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To: "David A. Cobb" <superbiskit AT home DOT com>, <cygwin-apps AT cygwin DOT com>
References: <3C18EBA9 DOT 9030102 AT ece DOT gatech DOT edu> <0b5501c184be$8639eb80$0200a8c0 AT lifelesswks> <3C1A35F6 DOT 8050909 AT ece DOT gatech DOT edu> <0f8901c185fc$a108b600$0200a8c0 AT lifelesswks> <3C1D5F00 DOT 3010506 AT ece DOT gatech DOT edu> <3C3384B2 DOT 8070305 AT home DOT com> <20020103002446 DOT GA8508 AT redhat DOT com> <3C35CD04 DOT 8070902 AT home DOT com>
Subject: Re: Restructuring gettext
Date: Sat, 5 Jan 2002 10:06:41 +1100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
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: 04 Jan 2002 23:08:17.0917 (UTC) FILETIME=[B20F32D0:01C19574]

----- Original Message -----
From: "David A. Cobb" <superbiskit AT home DOT com>
> > I've thought about suggesting the same thing but the problem with
that
> > scenario is that if you cancel an installation, then all sorts of
stuff
> > is uninstalled -- which probably isn't what you expected.
>
> Probably not.  But "cancel" at what point in the process?  It's *real*
> hard to program an installation procedure that's robust in the face of
a
> user clicking the "cancel" button in the middle.  Even the
> "professional" packages are likely to barf.

It's trivial to design. You treat an install like a series of
transactions. You make the transactions as small as you can while
satisfing all the system constraints - dependencies etc.

Once we've got per version dependencies and conflicts, and ordered
package actions (already described in this list) all we need to do is
make transactions that begin when a _current_ dependency/conflict is
being affected and finish when the system again has a consistent set of
dependencies and conflicts.

Additionally each package install/remove gets treated as an independent
transaction, to allow detection of in-use files.

Easy to code? Maybe not. Not too hard either. Replacing open files?
Sure. Already designed and proof-of-concept shown for setup.exe. How
many to queue at once? Until there are no in-process transactions.

The only restriction this puts on the setup process is that post install
scripts _must_ be able to be deferred until all the physical file
copying is complete.

Rob