[RFC] 1.7 Packaging: Obsolete packages

Corinna Vinschen corinna-cygwin@cygwin.com
Fri Aug 22 09:23:00 GMT 2008

On Aug 22 01:52, Brian Dessent wrote:
> 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?
> As far as the actual freeing of memory, I think it would go something
> like
> for (vector <packagemeta *>::iterator i = packages.begin ();
>      i != packages.end (); ++i)
>   {
>     delete *i;
>   }
> packages.clear();
> (And likewise for sourcePackages.)

If that works, it should be fairly simple.  Since the installed.db is
the first time read when pressing the "Next" button in the root dir
dialog, it might be best to place the cleanup above in the same
place, right before initializing the packagedb.

> > 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.

IMHO, the replaced-by would add nothing in terms of less maintainence
burden.  The old package still has to be tweaked in one way or another.
The only extra work without replaced-by is to create empty tar archives
for the old packages, which is really simple.


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

More information about the Cygwin-apps mailing list