David Airey <[email protected]> writes,
> I had log2html installed previously. [...] I typed,
>
> . ssc install log2html, replace
>
> [...] when I look in my ado dir by typing view ado dir, I _still_ have both
> versions of log2html. I have to manually remove the old version. This
> happens for all ssc installs. I don't think this behavior is helpful or
> expected, because I asked it to be replaced when I typed "replace".
>
> I view this as a bug.
It's not a bug, Stata behaves this way to handle a particular (and unlikely)
case, although upon reconsideration, Stata could act more sophisticatedly. I
will explain. Nick Cox <[email protected]> wrote,
> No bug, I think, but a misunderstanding. -ado dir- shows you a _history_ of
> what you have installed. [...]
There is some truth to that.
There are three cases I want to lead you through. Case 3 is the odd one
and the one that caused us to make -net install- and -ssc install- behave
as they do.
What is happening, case 1
-------------------------
Say I install a package named A, using either -net install- or -ssc install-.
A, we will assume, was not previously installed:
. ssc install A
Let's assume A provides three files:
A.ado
A.hlp
Later, let us assume, package A is updated. In the new package, the same two
files are provided. Anyway, we reinstall, and specify option -replace-:
. ssc install A, replace
If we were now to do a -ado dir-, it would appear as if we have two copies of
A installed. Actually, we do not. There is only one copy of A.ado and A.hlp;
they are just two directory entries.
Irritatingly, if we want to get rid of the old one, we have to manually -ado
uninstall- it.
What is happening, case 2
-------------------------
Same scenario as case 1, but this time, the original package A contains
three files:
A.ado
A_sub.ado
A.hlp
and the updated contains only two:
A.ado
A.hlp
This time, after we reinstall,
. ssc install A, replace
there is still only one coyp of A.ado and A.hlp, but A_sub.ado is left around,
attached to the originally A directory entry. As before, and irritatingly, if
we want to get rid of the old A, we must manually -ado uninstall- it. This
time, when we do that, A_sub.ado is erased, as well.
What is happening, case 3
-------------------------
Same scenario, but this time, the originally package A contained
A.ado
A.hlp
B.ado
B.hlp
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
A.ado
A.hlp
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 <[email protected]>. Kit nows
better than any of us how packages look and so can better evaluate the
frequency of case 3.
-- Bill
[email protected]
*
* For searches and help try:
* http://www.stata.com/support/faqs/res/findit.html
* http://www.stata.com/support/statalist/faq
* http://www.ats.ucla.edu/stat/stata/
