[plt-dev] planet remove and scribble

Sounds like the best thing would be for planet to detect that some
package depends on the to-be-removed package and then inform the user
that and do nothing, letting the user override that decision via some
flags that either give the upgrade behavior or removal of all
dependents.

Robby

On Fri, Feb 6, 2009 at 1:44 PM, Carl Eastlund <cce at ccs.neu.edu> wrote:
> On Fri, Feb 6, 2009 at 2:32 PM, Robby Findler
> <robby at eecs.northwestern.edu> wrote:
>> On Fri, Feb 6, 2009 at 1:22 PM, Carl Eastlund <cce at ccs.neu.edu> wrote:
>>> Hmm.  It does need to rebuild the index.  And it needs to rebuild the
>>> index without the package being removed.  But it doesn't want to
>>> reinstall the package if anything has a dependency on it... so it
>>> leaves the package installed.  That much makes sense.  Is there a way
>>> to do that, and either rebuild only the index (not any code /
>>> documentation) or else, when rebuilding other code, not follow
>>> dependencies into the package being removed?  I can see why it's doing
>>> some rebuilding, and why the package is still in place, but it seems
>>> unfortunate that it gets pulled into the actual build process.
>>>
>>> We could try another tack.  Remove the package, rebuild, but change
>>> the module resolver while rebuilding so that it reports an error
>>> during any attempts to retrieve that planet package.  That would
>>> rebuild as much of the index as possible without the package, wouldn't
>>> traverse the package itself, and wouldn't replace it with any new
>>> download.
>>
>> That seems like an interesting thing to try. The idea is that error
>> should never be signaled, right?
>
> No, the error may be signaled.  You may have A:1.0 and B:1.0 that
> depends on A:1.0+.  To upgrade A, you might first remove A:1.0 and
> then install A:1.1.  While removing A:1.0, B:1.0 will signal an error
> because nothing satisfies its dependence on A.  But that's an ok error
> to signal, it shouldn't interrupt setup-plt, but it does let the user
> know they have to replace A as their next step.
>
> If we're not trying to support this behavior of "remove a middle
> dependency and replace it later" -- which breaks down with multiple
> parts to the dependency anyway -- we should just remove the package
> outright and run setup-plt, and if anything depends on it that causes
> a re-download, the user "just shouldn't do that".
>
> Or, rather than special casing that you can't load that package,
> perhaps we should just disable the planet installation mechanism
> during planet remove -- no package should be installed, from web or
> from cache, during a remove.
>
> --Carl
>