Kip Warner wrote:
>>> Hey Max,
>>>
>>> If anything, it is that last thought that is certainly a matter of
>>> opinion. "uninstall" is an intuitive target, just like "all" and
>>> "install" as well.
>> It is? Personally, I think uninstall targets are silly, because I am
>> almost certain to have delete the build directory of something by the
>> time I am likely to want to uninstall it.
>>
>
> See section 14.5, "Standard Targets for Users".
>
> http://www.gnu.org/software/make/manual/make.html
>
>>> A piece of software as complex as subversion should
>>> have a standard means of removal, just like any other piece of software.
>>> The fact that we are dealing with just the source code is hardly any
>>> excuse.
>> My impression is that Subversion doesn't need to excuse itself, since
>> the world at large seems to have come to the consensus that
>> uninstallation is the role of package managers and similar, not build
>> systems.
>
> Isn't installation also a role of package managers? Why then do we have
> an install target?
>
>>> Having no efficient way to remove it is dangerous.
>> "Potentially messy", I'll accept. But "dangerous"?
>
> Sure. A user runs make install and a bunch of apr and neon libraries are
> installed into the system. Their package manager doesn't know about
> this, but the user knows that. When they are done, they would expect to
> make uninstall and, if they feel necessary, reinstall libapr or what
> have you and all is solved.
>
>>> Moreover, I
>>> am not the first person to have made note of this on the mailing list.
>> And I would argue that you and all previous people noting this simply
>> need to take note of the general reality that source installations do
>> not track their installed files.
>
> If make didn't know where it was copying the binaries, it wouldn't have
> been able to perform the operation to begin with.
>
>>> As for deleting all the files manually, note that you had to tell me
>>> that and, unlike an intuitive approach like an "uninstall" target,
>>> people aren't going to suspect that that was an option unless they ask
>>> here.
>> People aren't going aren't going to realize that deleting stuff is a
>> possible way to get rid of stuff? Of course they are. They just balk at
>> the complexity.
>
> There is the time factor as well, but that is another story. The means
> of manually deleting the files isn't mentioned in INSTALL either for
> building from tar ball.
>
>>> Also, searching for svn or subversion is not mentioned in INSTALL. What
>>> is mentioned, however, under the heading of "Building the Latest Source
>>> under Unix" (but not "Building from a Tarball or RPM") is that we must
>>> remove libsvn, libapr, libexpat, and libneon.
>> Certainly, but that part of INSTALL is not concerned with uninstalling
>> Subversion, merely with getting potentially problematic libraries out of
>> the way.
>
> Why are they not a problem for building from a tar ball? And before you
> answer that, think about the fact that you had to tell me this here
> rather than just in the INSTALL.
>
>> Bottom line is: writing a sane 'make uninstall' for Subversion is a
>> vastly non-trivial undertaking (not least because you would first have
>> to go get a 'make uninstall' added to apr, apr-util and neon) that I
>> doubt anyone will ever feel sufficiently motivated to do it.
>
> That is a good point, but it can still be done.
No, you can't. You can never get 100% accurate software uninstallation
without having a rigid package system that knows every single thing that
has been installed and it's requirements.
This is because you need to be able to identify every single piece of
existing software that may still be using the libraries the svn source
installs, and then, not delete those libraries that are still needed by
that software. Otherwise, you'll break that software (for example,
subversion guis that use the bindings, or python scripts using the
python bindings)
You could start by looking at the shared library requirements of every
binary and other library on your system, but this isn't enough, because
things can dynamic load libaries.
You could then look through all the strings contained in the binary to
see if it has the name of one of our subversion libraries.
This still isn't enough, because i could put those names in a data file
separate from the binary.
So you'd have to go searching through every file on the hd to see if the
names of the libraries occur.
But then i could just subtract out the common prefix and suffix in libs
or some subset thereof, so you'd really need to see if "libsvn_fs.so",
"svn_fs", or "svn_fs.so", or "libsvn_fs" existed anywhere.
This doesn't even begin to cover the issues with ensuring you don't
remove the bindings if things are still using them.
Bottom line: It is insanity to think we can write a make uninstall that
users wouldn't complain about.
HTH,
Dan
>
>> Max.
>>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Aug 7 02:11:15 2006