From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15827 invoked by alias); 22 Aug 2008 10:54:10 -0000 Received: (qmail 15662 invoked by uid 22791); 22 Aug 2008 10:54:08 -0000 X-Spam-Check-By: sourceware.org Received: from dessent.net (HELO dessent.net) (69.60.119.225) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 22 Aug 2008 10:53:32 +0000 Received: from localhost.localdomain ([127.0.0.1] helo=dessent.net) by dessent.net with esmtp (Exim 4.50) id 1KWUGn-0001hp-Nd for cygwin-apps@cygwin.com; Fri, 22 Aug 2008 10:53:29 +0000 Message-ID: <48AE9AA8.D30720B9@dessent.net> Date: Fri, 22 Aug 2008 10:54:00 -0000 From: Brian Dessent Reply-To: cygwin-apps@cygwin.com X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) MIME-Version: 1.0 To: cygwin-apps@cygwin.com Subject: Re: [RFC] 1.7 Packaging: Obsolete packages References: <20080725094034.GR5251@calimero.vinschen.de> <20080730121815.GM29031@calimero.vinschen.de> <48ACED44.4060902@users.sourceforge.net> <20080821082602.GE29104@calimero.vinschen.de> <20080821103526.GJ29104@calimero.vinschen.de> <20080821114626.GL29104@calimero.vinschen.de> <48AE1681.87EFAB55@dessent.net> <20080822081956.GB29992@calimero.vinschen.de> <48AE7E50.483A42C0@dessent.net> <20080822092437.GS29104@calimero.vinschen.de> <20080822101259.GT29104@calimero.vinschen.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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-08/txt/msg00238.txt.bz2 Corinna Vinschen wrote: > Something's obviously missing... Yes, I led you astray, sorry. That is going to purge absolutely everything that setup knows about packages. In order to get that back it would be necessary to re-parse setup.ini and re-scan the local package directory for its contents to see what's available. What's needed is rather than nuking the database, to undo the information about what versions are currently installed. This is rather dicey because each packagemeta contains a std::set of packageversions, each of which could have come from setup.ini, or from the parsing of the filename in installed.db. So we can't just remove everything from that set. But if you don't remove anything you'd leak (or end up with duplicates, or end up with nonsense versions) because the code in the installed.db reader (below) creates a new packageversion unconditionally. Really what we want to do is undo this: packageversion binary = cygpackage::createInstance (pkgname, inst, instsz, f.ver, package_installed, package_binary); pkg->add_version (binary); pkg->set_installed (binary); pkg->desired = pkg->installed; I think what might be required is to add another field to packageversion to denote whether it came from reading setup.ini or from reading installed.db. (Remember that it's possible that the installed version is not Curr nor Prev nor Exp, it could be anything.) Then add a method to packagemeta that removes from 'versions' any that came from installed.db, leaving the ones that came from setup.ini. (This will need an operator delete to balance the operator new in cygpackage::createInstance otherwise it leaks.) Then we can call that method on each packagemeta in the packagedb::packages vector. We'll also need to set the 'desired' and 'installed' members to point to something sensible, because otherwise they are potentially dangling if they pointed to something we removed. I'm not sure what that something is, but to find out you can put some debugging statements in and find out what everything looks like after parsing setup.ini and scanning the local package dir but prior to reading installed.db to find out how to reverse the changes. Brian