This is the mail archive of the cygwin-apps mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] 1.7 Packaging: Obsolete packages

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]