Mailing-List:	contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive:	<http://sources.redhat.com/ml/cygwin/>
List-Post:	<mailto:cygwin AT sources DOT redhat DOT com>
List-Help:	<mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender:	cygwin-owner AT sources DOT redhat DOT com
Delivered-To:	mailing list cygwin AT sources DOT redhat DOT com
Date:	Mon, 20 Nov 2000 13:24:12 EST
X-Mailer:	Virtual Access by Atlantic Coast PLC, http://www.atlantic-coast.com/va
Message-Id:	<VA.00000569.00534b44@thesoftwaresource.com>
To:	cygwin AT cygwin DOT com
Subject:	Re: setup.exe should remove the tar.gz files of old packages
In-Reply-To:	<200011200411.XAA27560@envy.delorie.com>
From:	Brian Keener <bkeener AT thesoftwaresource DOT com>
Reply-To:	bkeener AT thesoftwaresource DOT com

DJ Delorie wrote:
> Perhaps the user can just delete the files they don't want?  It's not
> a big deal, and we already have more options than I'm comfortable
> with.

I think this is my preferred method.  I at one time thought it would be 
nice if we added the additional logic to cleanup latest and contrib but 
the more I have worked with setup and all that it involves, I really 
believe the cleanup should be left to the user.  As you say - what if we 
have packages which the user manually added to latest and contrib, what 
if the package is not using version numbers at this time or as in the 
case of one package I saw the version number gets changed and the new is 
actually a lesser version than the old.

> Usually, setup.ini knows about the previous stable release.  The
> tricky parts are the .gz files no longer listed in setup.ini.
>
> I suppose we could try to be clever and only remove old versions of
> *known* packages.

What with the copy of setup.ini and the installeddb and even the method 
we use to search for the tarballs on the disk we have a lot of tools 
available to look for known packages, but I still think we need to leave 
to the user or we end up having a previnstalleddb and/or adding to 
setup.ini a new classification like *obsolete*, as we have for prev, 
curr, and test.

With the way installeddb and setup.ini currently work - we don't have to 
do a lot of cleanup on them and the user can delete the tarballs as he 
sees fit.  If we try to cleanup - suddenly installeddb and setup.ini 
require more maintenance from with setup.

Just my 2 cents worth.






--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com

- Raw text -