From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29389 invoked by alias); 25 Jul 2008 16:13:18 -0000 Received: (qmail 29378 invoked by uid 22791); 25 Jul 2008 16:13:18 -0000 X-Spam-Check-By: sourceware.org Received: from pool-72-93-245-95.bstnma.fios.verizon.net (HELO ednor.cgf.cx) (72.93.245.95) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 25 Jul 2008 16:13:00 +0000 Received: by ednor.cgf.cx (Postfix, from userid 201) id 22D532B353; Fri, 25 Jul 2008 12:12:59 -0400 (EDT) Date: Fri, 25 Jul 2008 16:13:00 -0000 From: Christopher Faylor To: cygwin-apps@cygwin.com Subject: Re: [RFC] 1.7 Packaging: Obsolete packages Message-ID: <20080725161259.GC10812@ednor.casa.cgf.cx> Reply-To: cygwin-apps@cygwin.com Mail-Followup-To: cygwin-apps@cygwin.com References: <48880879.5050400@users.sourceforge.net> <20080724094313.GG5251@calimero.vinschen.de> <488913D9.8070809@users.sourceforge.net> <20080725094034.GR5251@calimero.vinschen.de> <20080725145243.GB9959@ednor.casa.cgf.cx> <20080725151630.GW5251@calimero.vinschen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080725151630.GW5251@calimero.vinschen.de> User-Agent: Mutt/1.5.16 (2007-06-09) Mailing-List: contact cygwin-apps-help@cygwin.com; run by ezmlm Precedence: bulk Sender: cygwin-apps-owner@cygwin.com List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Mail-Followup-To: cygwin-apps@cygwin.com X-SW-Source: 2008-07/txt/msg00139.txt.bz2 On Fri, Jul 25, 2008 at 05:16:30PM +0200, Corinna Vinschen wrote: >On Jul 25 10:52, Christopher Faylor wrote: >> On Fri, Jul 25, 2008 at 11:40:34AM +0200, Corinna Vinschen wrote: >> >Nice example. Still, for now we should assume that we go the upgrade >> >path. I'm going to investigate the impact of a clean cut in the next >> >couple of days. >> >> It seems like maybe another change to setup.exe would be in order here >> or maybe there could be a base package which did any cleanup required to >> purge unneeded packages. > >Another base package sounds like an interesting idea. OTOH, setup would >use the existing local setup database and might get something wrong >before the new base package has a chance to do the cleanup. Baah. >Maybe we could provide an upgrade helper script which should run *before* >running setup for the ultimate upgrade. I was thinking of a variation of _update_info which waited until everything was done before it started doing anything. You could even write a mingw app which didn't rely on cygwin to do some of the work. cgf