Re: [RFC] 1.7 Packaging: Obsolete packages

[Corinna Vinschen <corinna-cygwin@cygwin.com>]

On Aug 21 18:29, Brian Dessent wrote:
> Corinna Vinschen wrote:
> 
> > IIUC, the ConnectedLoopFinder::visit() function is the core function
> > which creates the dependency order.  What I don't get is this: The
> 
> That code is concerned with creating a topological ordering for the
> specific purpose of running postinstall scripts.  This isn't called
> until after the "remove old and unpack new" install phase is finished
> [...]

Oh, cool, I was looking into the wrong code all the time.  No surprise
I coudn't figure out how it works.

> If you want to see a general example of dependency handling when a
> package is selected, see ChooserPage::changeTrust (what is called when
> you change everything at once, e.g. Curr to Exp) or
> PickPackageLine::click (what is called when you click on a package.)  In
> both cases the main workhorse is packagemeta::set_requirements and in
> turn packageversion::set_requirements.  The logic for Replaces would
> probably have to be wedged in there.

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?

> But it's a lot harder than just adding some code to deselect the
> packages -- consider if setup followed the "Replaces:" advice and
> unselected some packages because the user selected a new package, but
> then they changed their mind and deselected that same package.  If we
> don't go back and re-enable those packages then we potentially leave
> them with a broken system.  We could delay this processing until later
> in the process when the user no longer can change their mind, but then
> the package selection pane becomes a lie.  We will potentially be
> removing stuff that isn't marked as remove, and the "Selected" view no
> longer accurately serves as a "here's a list of everything I'm about to
> do" summary which I think is a valuable feature.

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.

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?


Corinna

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