Stata The Stata listserver
[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]

st: ado uninstall behavior

From   Kit Baum <>
Subject   st: ado uninstall behavior
Date   Mon, 16 Jun 2003 16:02:38 -0400

On 12 June 2003 Bill Gould wrote:


What is happening, case 3
- -------------------------

Same scenario, but this time, the originally package A contained


You have seen packages like this: the author says "install this package,
and you will get two things, A and B."

Later, A is updated. Just to make things interesting, let's pretend this time
that A is updated not by the originally author, but by someone else. That is
not necessary, but it makes the story more interesting. Anyway, in the new A
included are


B is not included in the "updated" package because the updating author
cared nothing about B, or had no updates to offer.

So now when you reinstall A,

. ssc install A, replace

You still have two A's installed. A.ado and A.hlp are part of the new A.
The old A has in it B.ado and B.hlp.

That's useful because, had Stata really removed the old A, you would have
lost B.ado and B.hlp, and you might still want that. If you do not,
you can manually uninstall the old A.

What could be better
- --------------------

Stata cannot tell case 2 from case 3, but case 1 is certainly distinguishable.
Stata could, in case 1, go ahead and remove the old A directory entry which,
in fact, serves no purpose. Case 1 is the most common case, to boot. That
sounds better to me, but it bothers me a little that Stata's behavior becomes
a little unpredictable beforehand. Do you need to uninstall the old A? With
the improvement, only if it is still there and you know you don't want it.

Another altnernative would be to recognize that case 3 rarely happens and, if
authors do a good job constructing packages, should never occur. You must
remember that we wrote -net install- *BEFORE* we knew how users would use it.
Anyway, case 3 is rare, so let's forget it, and change -replace- to mean
- -uninstall-, so the command would work just as David expects.

I suggest that we leave the decision up to Kit Baum <>. Kit nows
better than any of us how packages look and so can better evaluate the
frequency of case 3.

I think case 3 is indeed rather rare. I don't think if it does appear it indicates that authors are building packages sloppily; case 3 arises when, e.g., someone figures out that they can just call one of Nick's routines rather than inline coding it. At some later date, they may no longer need that routine, or decide that it is worth it to code the subset of the other file inline. So their revised package no longer calls for B. Admittedly if 'replace' meant 'bring up to date, and remove all no-longer-current code' you would lose B; but that is easy enough to rectify.

Another situation in which this may happen is where the author used private code B, which is now integrated into Stata. Then B is truly obsolete, in the sense that everyone should prefer to use the supported version rather than the privately authored version (e.g. -levels-).

So I see no problem in revising -net install, replace- and -ssc install, replace- to do a cleanup job when executed.

Kit Baum
SSC archive maintainer

* For searches and help try:

© Copyright 1996–2019 StataCorp LLC   |   Terms of use   |   Privacy   |   Contact us   |   What's new   |   Site index