From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16899 invoked by alias); 22 Aug 2008 08:53:10 -0000 Received: (qmail 16887 invoked by uid 22791); 22 Aug 2008 08:53:09 -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 08:52:35 +0000 Received: from localhost.localdomain ([127.0.0.1] helo=dessent.net) by dessent.net with esmtp (Exim 4.50) id 1KWSNk-0001Az-ND for cygwin-apps@cygwin.com; Fri, 22 Aug 2008 08:52:32 +0000 Message-ID: <48AE7E50.483A42C0@dessent.net> Date: Fri, 22 Aug 2008 08:53: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: <48880879.5050400@users.sourceforge.net> <20080724094313.GG5251@calimero.vinschen.de> <488913D9.8070809@users.sourceforge.net> <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> 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/msg00230.txt.bz2 Corinna Vinschen wrote: > Ok, I'll have a look. Any idea about my other question? How to remove > the entire installed.db package DB when the user goes back to the root > dir selection dialog so we can reload from another location, should the > user choose one? My aborted unfinished attempt at a 1.7 setup also suffered from this. The plan of attack that I had was to move the code that reads installed.db out of the packagedb ctor and into its own private or static function. Then write a new member function that first frees the in-memory copy (if it exists) and then calls that reader function. Then hook this function into the wizard dialog so that it's called every time you move off the rootpage. As far as the actual freeing of memory, I think it would go something like for (vector ::iterator i = packages.begin (); i != packages.end (); ++i) { delete *i; } packages.clear(); (And likewise for sourcePackages.) Yes, it royally sucks that setup has this horrific mix of containers as well as explicit pointer management. Ideally it would be great to eliminate all explicit new/delete housekeeping and instead make them smart pointers, but that's a big project. > Is that really a big point? The "replaces" stuff is meant to seemlessly > replace one package with (usually) a functionally at least equivalent > package. There shouldn't be much of a difference for the user. You mean is it not a big point that the uninstallation of the packages listed in "Replaces:" wouldn't be indicated anywhre? Yes, I suppose it's somewhat of a minor point. But I really do think that setup has enough odd and inexplicable behavior already that I hesitate to add more -- being able to always double check the precise set of install/remove/upgrade operations that are about to take place with the "Partial" view is a useful debugging tool. > OTOH, a "replaces" rule does not allow to replace an obsolete package > automatically. So, if we want to upgrade the user automatically to the > new packages, we would *still* have to provide empty obsolete packages > with a setup.hint requiring the new packages. > > What would the "replaces" rule buy us again? I don't know. Maybe what is needed is a key that works in the other direction, "Replaced-by:" with the semantics of: if this package is currently installed then de-install it and install everything in the specified list. So to rename/split a package you would upload the new package(s) under the new name(s), move the old package to category _obsolete (so that it's not shown) and add a "Replaced-by: newname" line. This would cause a silent upgrade for everyone the next time they ran setup, the same way that bumping the version and uploading an empty file does today. Off the top of my head, complication with this idea: - the Replaced-by would have to be transitive in the dependency computation code as well. So if a maintainer renames package OLDNAME to NEWNAME, then a package that "requires:" OLDNAME would have to have OLDNAME replaced with NEWNAME in the internal representation of the dependency list. It's tempting to say that the maintainer should just add NEWNAME to the "requires:" of OLDNAME, and let the requirement chain. But I don't think that would fly because what we're saying with this keyword is that OLDNAME won't be installed any more. This is in opposition to the current method where OLDNAME does actually stay installed (in the mind of setup) but contains an empty payload so has no footprint. - the Replaced-by method would not allow a determined user to continue using an old version of a package without upgrading. With the current scheme they can just mark the existing package as "Keep" (or select a "Prev" version) which has the effect of blocking the upgrade since it works on the principle of the bumped version triggering the action. But with a Replaced-by keyword doing the action instead of the presence of a bumped version, there would be no choice. Brian