delorie.com/archives/browse.cgi | search |
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 |
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
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |