This is the mail archive of the
mailing list for the Cygwin project.
Re: [RFC] 1.7 Packaging: Obsolete packages
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
for (vector <packagemeta *>::iterator i = packages.begin ();
i != packages.end (); ++i)
(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
> 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
- 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.