Re: [RFC] 1.7 Packaging: Obsolete packages

[Brian Dessent <brian at dessent dot net>]

Brian Dessent wrote:

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

And thinking about this some more, we could work around that issue by
implementing the treatment of the Replaced-by keyword "as-if" the user
had manually deselected OLDNAME and selected NEWNAME.  Thus if they
select "Keep" then that action is undone and the list of operations is
cleared as expected, and all packages stay at what they're set to now. 
Of course we'd need to hook it into the right places so that these
"as-if" selections are not just done once but every time that the trust
level is set to "Curr".  Otherwise, you'd miss the upgrade if you
clicked on Keep then clicked again on Curr (or Exp for that matter.)

So to sum up an implementation skeleton:

- add the keyword to the lexer and parser
- add an additional packagedb data member that contains a vector of
OLDNAME->NEWNAME pairs found from the result of parsing the ini file
- add code that runs after reading the installed.db that changes any
occurance of OLDNAME to NEWNAME in any package's dependency spec
- add code in the "set global trustval" codepath that runs after all the
exising calculations to set the transitions "as-if" the user had
deselected OLDNAME and selected NEWNAME for each pair, recomputing full
recursive dependencies each time -- but *only* if setting the trustval
to curr or exp, not keep.

Brian