You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Kip Warner <Ki...@TheVertigo.com> on 2006/08/05 20:58:13 UTC
Uninstalling Subversion
I checked the mailing list, and unless I am mistaken, there is no
uninstall target in the makefile...
I would like to uninstall Subversion when 1.4 moves from branch to tag
officially, but I can't seem to do this? There are too many files to
track manually. The reason being is that I would rather apt knew about
Subversion, so I will use the 1.4 package when it is released rather
than using the makefile to install it.
I configured and built it myself, so it isn't as simple as using apt or
rpm.
Is there some script or some way of removing it? If not, this should
surely be noted first in the INSTALL before people even begin to
compile.
--
Kip Warner
Vertigo
http://TheVertigo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Uninstalling Subversion
Posted by Eric Hanchrow <of...@blarg.net>.
>>>>> "Kip" == Kip Warner <Ki...@TheVertigo.com> writes:
Kip> I checked the mailing list, and unless I am mistaken, there
Kip> is no uninstall target in the makefile...
I hate that.
Kip> I would like to uninstall Subversion when 1.4 moves from
Kip> branch to tag officially, but I can't seem to do this?
No advice for you now, since you've already installed it. But in the
future, consider using GNU "stow" when installing stuff -- it solves
precisely this problem. I use it for everything that I build from
source.
--
... there are any number of partisan Democrats lurking in
engineering departments and liberal moles in software-writing
offices.
-- Molly Ivins
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Uninstalling Subversion
Posted by Branko Čibej <br...@xbc.nu>.
Kip Warner wrote:
> On Sat, 2006-05-08 at 22:51 +0100, Max Bowsher wrote:
>
>> Kip Warner wrote:
>>
>>> I checked the mailing list, and unless I am mistaken, there is no
>>> uninstall target in the makefile...
>>>
>> Indeed. An 'uninstall' target is far from standard.
>>
>>
>>> I would like to uninstall Subversion when 1.4 moves from branch to tag
>>> officially, but I can't seem to do this? There are too many files to
>>> track manually.
>>>
>> That's a matter of opinion, but there are quite a few, yes.
>> On the other hand, searching for filenames containing 'svn' or
>> 'subversion' gets you most (all?) of them.
>>
>>
>>> I configured and built it myself, so it isn't as simple as using apt or
>>> rpm.
>>>
>>> Is there some script or some way of removing it?
>>>
>> Delete all the files manually.
>>
>>
>>> If not, this should surely be noted first in the INSTALL before
>>> people even begin to compile.
>>>
>> Why do you think so? This is hardly a matter in which Subversion is
>> exceptional. Rather, it is the common case for source installations.
>>
>> Max.
>>
>
> 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. 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. Having no efficient way to remove it is dangerous. Moreover, I
> am not the first person to have made note of this on the mailing list.
>
> 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.
>
> 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.
>
We assume that people who are playing around with the source know what
they are doing, or take the time to learn. These days, most users just
grab a binary distro (whether .rpm, ..deb or .msi), all of which do
support uninstallation.
It should be fairly trivial to build, say, an RPM from SVN's source
tree, since we include RPM config scripts, too.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Uninstalling Subversion
Posted by Daniel Berlin <db...@dberlin.org>.
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
Re: Uninstalling Subversion
Posted by Max Bowsher <ma...@ukf.net>.
Kip Warner wrote:
> On Sun, 2006-06-08 at 00:08 +0100, Max Bowsher wrote:
>> Fact: 'make uninstall' requires that you preserve the build directory
>> for when you want to uninstall the package.
>
> So what? You've got it if you compiled from source anyways.
I treat build directories as temporary artefacts, and delete them after
I've installed something. They are fairly large and of little use after
a successful installation. So, no, I don't have them.
>> As a result, it is too cumbersome to be widely adopted as a general
>> means of package uninstallation.
>
>> As a result, maintainers are reluctant to bother coding uninstall targets.
>
> I cannot confirm that at all. Everything from the NIC drivers on my
> system to the games and gnome utilities all have uninstall targets.
>
>> GNU may mandate it for their own software, uptake of the idea in non-GNU
>> software is severely limited.
>
> They weren't talking about their own software, but software which uses
> make, as I understood it. Hence why everyone else uses the targets.
>
>> Any user who expects 'make uninstall' to be present as a matter of
>> course has expectations that correspond poorly to reality.
>
> If by reality, you are talking about the set of assumptions inside
> developers' heads, who are *RESPONSIBLE* for svn's development, then
> yes, I do have a very poor conception of reality. But understand that it
> all seems very clear to you, but that is only because you are probably
> involved in the project. It is unreasonable to deviate from common
> methodologies when there is no reason to. Even if you can find instances
> where uninstall target is not implemented, it does not change the fact
> that people intuitively expect it. But more importantly, it is useful.
My opinions are formed by the set of software that I typically work
with, in which the uninstall target is a seldom encountered and largely
irrelevant oddity. I do NOT intuitively expect it.
I can only assume that the set of software that you typically work with
is very different to mine, leading to the formation of a strongly
different world-view on this topic between you and I.
Max.
Re: Uninstalling Subversion
Posted by Kip Warner <Ki...@TheVertigo.com>.
On Sun, 2006-06-08 at 00:08 +0100, Max Bowsher wrote:
> Fact: 'make uninstall' requires that you preserve the build directory
> for when you want to uninstall the package.
So what? You've got it if you compiled from source anyways. If you
wanted something official, you would have just use a packaged binary.
> As a result, it is too cumbersome to be widely adopted as a general
> means of package uninstallation.
> As a result, maintainers are reluctant to bother coding uninstall targets.
I cannot confirm that at all. Everything from the NIC drivers on my
system to the games and gnome utilities all have uninstall targets.
> GNU may mandate it for their own software, uptake of the idea in non-GNU
> software is severely limited.
They weren't talking about their own software, but software which uses
make, as I understood it. Hence why everyone else uses the targets.
> Any user who expects 'make uninstall' to be present as a matter of
> course has expectations that correspond poorly to reality.
If by reality, you are talking about the set of assumptions inside
developers' heads, who are *RESPONSIBLE* for svn's development, then
yes, I do have a very poor conception of reality. But understand that it
all seems very clear to you, but that is only because you are probably
involved in the project. It is unreasonable to deviate from common
methodologies when there is no reason to. Even if you can find instances
where uninstall target is not implemented, it does not change the fact
that people intuitively expect it. But more importantly, it is useful.
> The careful management of a system over time has become solely the
> domain of package managers. The usual demands of a software build system
> are to simply place the appropriate files in a nominated directory tree,
> be that a live system or a staging directory.
Why do we implement an install target then? Surely that should be left
to the package manager's domain?
>
> > If make didn't know where it was copying the binaries, it wouldn't have
> > been able to perform the operation to begin with.
>
> I'm sorry, I can't resist: 'make' never copies anything! :-)
> Before you suggest adding lots of echos to a file into the makefiles:
> once libtool gets involved, the makefiles themselves aren't fully aware
> of all the filenames they are causing to be installed anyway.
This is painfully and blatantly obvious. Ultimately it resolves down to
cp doing its thing. The point being is that it must have gotten its
arguments from somewhere.
>
> >> 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.
>
> But vanishingly unlikely that it ever will be.
>
> Max.
>
I will look into Eric's suggestion of using stow.
Vale,
--
Kip Warner
Vertigo
http://TheVertigo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Uninstalling Subversion
Posted by Max Bowsher <ma...@ukf.net>.
Fact: 'make uninstall' requires that you preserve the build directory
for when you want to uninstall the package.
As a result, it is too cumbersome to be widely adopted as a general
means of package uninstallation.
As a result, maintainers are reluctant to bother coding uninstall targets.
GNU may mandate it for their own software, uptake of the idea in non-GNU
software is severely limited.
Any user who expects 'make uninstall' to be present as a matter of
course has expectations that correspond poorly to reality.
The careful management of a system over time has become solely the
domain of package managers. The usual demands of a software build system
are to simply place the appropriate files in a nominated directory tree,
be that a live system or a staging directory.
> If make didn't know where it was copying the binaries, it wouldn't have
> been able to perform the operation to begin with.
I'm sorry, I can't resist: 'make' never copies anything! :-)
Before you suggest adding lots of echos to a file into the makefiles:
once libtool gets involved, the makefiles themselves aren't fully aware
of all the filenames they are causing to be installed anyway.
>> 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.
But vanishingly unlikely that it ever will be.
Max.
Re: Uninstalling Subversion
Posted by Kip Warner <Ki...@TheVertigo.com>.
On Sun, 2006-20-08 at 15:51 -0600, Bob Proulx wrote:
> Kip Warner wrote:
> > Thanks Bob. Makes perfect sense. Are the child directories in /usr
> > precede /usr/local in the order in which they appear in the path
> > environment variable?
>
> I did not quite follow the question but will try to answer it anyway.
> Usually a user's environment will include their personal directories,
> the system local directories, and official system directories.
> Basically these in pretty much this order:
>
> PATH=$HOME/bin:/usr/local/bin:/usr/bin:/bin
>
> This allows a priority of program selection with the version preferred
> by the user first, the local admin second and the system third. That
> is not an exclusive list. Both FHS and non-FHS systems have other
> directories too (e.g. /opt/bin, /usr/ccs/bin, /usr/xpg4/bin, etc.) but
> for the sake of this discussion the above is a good place to start.
> The above works as a good default.
>
> Most system processes will be just like the above but without any
> user's home and with the system binary directory. (Used to be
> statically linked system directory, but that is another story.)
>
> PATH=/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
>
> But some system processes will want to avoid commands other than
> exactly the ones they are designed to work with and tested. There may
> be security implications in some cases. Those commands will eschew
> non-system directories and stick to just the system installed
> commands.
>
> PATH=/usr/bin:/bin:/usr/sbin:/sbin
>
> It is a judgement call as to which PATH any particular process uses.
> And different systems lean toward slightly different operating and
> security models than others and so there are variations. Some use
> 'staff' sgid directories, 'wheel' groups, etc. All generalities are
> false, including this one.
>
> Bob
>
Thank you Bob. Invaluable.
--
Kip Warner
Vertigo
http://TheVertigo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Uninstalling Subversion
Posted by Bob Proulx <bo...@proulx.com>.
Kip Warner wrote:
> Thanks Bob. Makes perfect sense. Are the child directories in /usr
> precede /usr/local in the order in which they appear in the path
> environment variable?
I did not quite follow the question but will try to answer it anyway.
Usually a user's environment will include their personal directories,
the system local directories, and official system directories.
Basically these in pretty much this order:
PATH=$HOME/bin:/usr/local/bin:/usr/bin:/bin
This allows a priority of program selection with the version preferred
by the user first, the local admin second and the system third. That
is not an exclusive list. Both FHS and non-FHS systems have other
directories too (e.g. /opt/bin, /usr/ccs/bin, /usr/xpg4/bin, etc.) but
for the sake of this discussion the above is a good place to start.
The above works as a good default.
Most system processes will be just like the above but without any
user's home and with the system binary directory. (Used to be
statically linked system directory, but that is another story.)
PATH=/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
But some system processes will want to avoid commands other than
exactly the ones they are designed to work with and tested. There may
be security implications in some cases. Those commands will eschew
non-system directories and stick to just the system installed
commands.
PATH=/usr/bin:/bin:/usr/sbin:/sbin
It is a judgement call as to which PATH any particular process uses.
And different systems lean toward slightly different operating and
security models than others and so there are variations. Some use
'staff' sgid directories, 'wheel' groups, etc. All generalities are
false, including this one.
Bob
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Uninstalling Subversion
Posted by Bob Proulx <bo...@proulx.com>.
Kip Warner wrote:
> Speaking of which, most of my stuff installs to /usr when I use
> packages, but /usr/local when I use install targets for make. Why is
> that? What is the difference between local and it's parent?
If you were to copy files to /usr on top of files already managed by a
package manager then you have created a situation where files are
corrupted as seen by the package manager and not managed by other
means. This appears as the "person with two watches never knows the
correct time" problem.
If you previously had svn installed using a package manager then 'make
install' into /usr would corrupt the installation. Removing the
package from the package manager would break the 'make install'
installation. Because both are poured into the same /usr directory it
is now a problem to know which files are managed by the package
manager and which are copied there by the user.
Files in /usr/local are solely the domain of the local admin. No
files are installed there by packages. (No packages from a
distribution. Local admins may create their own packages with files
there. By definitely that is a local change by the local admin.)
Therefore by default 'make install' will put all files in /usr/local
to eliminates any chance of collision with a file owned by a package,
a.k.a. /usr, the system. (If a local admin 'make install's on top of
a file from a locally built package then it would be their own fault
and arguably what they wanted to do because that is what they did.)
The /usr system above does not care about files in /usr/local and
files from /usr/local could be added or removed at any time without
breaking the system above it. They should be operating mostly
independently from each other. There is almost always some
cross-talk. But within reason this works pretty well.
Bob
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Uninstalling Subversion
Posted by Kip Warner <Ki...@TheVertigo.com>.
On Sun, 2006-13-08 at 18:02 +0100, Barry Scott wrote:
> On Aug 7, 2006, at 18:07, Daniel Rall wrote:
>
> > Kip, if you're building and installing from source, I suggest using an
> > alternate --prefix argument to configure (e.g. "/usr/local/subversion"
> > instead of "/usr" or "/usr/local").
> >
> > The type of "uninstall" you're looking for becomes a 'mv' or 'rm -r'
> > of the prefix.
>
> Using prefix is a good solution. However here is how to turn install
> into uninstall - so long as the files are not in use else where.
>
> make install DESTDIR=/tmp/qqq
> cd /tmp/qqq
> find . -type f -exec rm {} ';'
> rm -rf /tmp/qqq
>
> Barry
>
>
Barry, you've solved my problem! All I have to do is take a peek inside
the DESTDIR now and just remove everything's equivalent in /usr.
Speaking of which, most of my stuff installs to /usr when I use
packages, but /usr/local when I use install targets for make. Why is
that? What is the difference between local and it's parent?
--
Kip Warner
Vertigo
http://TheVertigo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Uninstalling Subversion
Posted by Barry Scott <ba...@barrys-emacs.org>.
On Aug 7, 2006, at 18:07, Daniel Rall wrote:
> Kip, if you're building and installing from source, I suggest using an
> alternate --prefix argument to configure (e.g. "/usr/local/subversion"
> instead of "/usr" or "/usr/local").
>
> The type of "uninstall" you're looking for becomes a 'mv' or 'rm -r'
> of the prefix.
Using prefix is a good solution. However here is how to turn install
into uninstall - so long as the files are not in use else where.
make install DESTDIR=/tmp/qqq
cd /tmp/qqq
find . -type f -exec rm {} ';'
rm -rf /tmp/qqq
Barry
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Uninstalling Subversion
Posted by Daniel Rall <dl...@collab.net>.
Kip, if you're building and installing from source, I suggest using an
alternate --prefix argument to configure (e.g. "/usr/local/subversion"
instead of "/usr" or "/usr/local").
The type of "uninstall" you're looking for becomes a 'mv' or 'rm -r'
of the prefix.
Re: Uninstalling Subversion
Posted by Kip Warner <Ki...@TheVertigo.com>.
> The point being is that if we have an install target, it doesn't make
> sense to have something that simply negates the process.
I mean to *not* have something that simply negates the process.
--
Kip Warner
Vertigo
http://TheVertigo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Uninstalling Subversion
Posted by Kip Warner <Ki...@TheVertigo.com>.
On Sun, 2006-06-08 at 00:17 +0100, Philip Martin wrote:
> Kip Warner <Ki...@TheVertigo.com> writes:
>
> > Isn't installation also a role of package managers? Why then do we have
> > an install target?
>
> How else would you build a package?
It would output its libs and executables at the end of the build process
into a child directory called "output" or some such. Inside would be the
directory layout as represented on the system or something like that.
The .spec of whatever package creation software you are using can take
it from there.
I am not saying this is a good solution, only that it seems to be the
only option if we leave tasks that are seen to be of the package
manager's domain to the package managers.
The point being is that if we have an install target, it doesn't make
sense to have something that simply negates the process.
--
Kip Warner
Vertigo
http://TheVertigo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Uninstalling Subversion
Posted by Philip Martin <ph...@codematters.co.uk>.
Kip Warner <Ki...@TheVertigo.com> writes:
> Isn't installation also a role of package managers? Why then do we have
> an install target?
How else would you build a package?
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Uninstalling Subversion
Posted by Kip Warner <Ki...@TheVertigo.com>.
> > 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.
>
> Max.
>
>
>
--
Kip Warner
Vertigo
http://TheVertigo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Uninstalling Subversion
Posted by Max Bowsher <ma...@ukf.net>.
Kip Warner wrote:
> On Sat, 2006-05-08 at 22:51 +0100, Max Bowsher wrote:
>> Kip Warner wrote:
>>> I checked the mailing list, and unless I am mistaken, there is no
>>> uninstall target in the makefile...
>> Indeed. An 'uninstall' target is far from standard.
>>
>>> I would like to uninstall Subversion when 1.4 moves from branch to tag
>>> officially, but I can't seem to do this? There are too many files to
>>> track manually.
>> That's a matter of opinion, but there are quite a few, yes.
>> On the other hand, searching for filenames containing 'svn' or
>> 'subversion' gets you most (all?) of them.
>>
>>> I configured and built it myself, so it isn't as simple as using apt or
>>> rpm.
>>>
>>> Is there some script or some way of removing it?
>> Delete all the files manually.
>>
>>> If not, this should surely be noted first in the INSTALL before
>>> people even begin to compile.
>> Why do you think so? This is hardly a matter in which Subversion is
>> exceptional. Rather, it is the common case for source installations.
>>
>> Max.
>
> 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.
> 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.
> Having no efficient way to remove it is dangerous.
"Potentially messy", I'll accept. But "dangerous"?
> 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.
> 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.
> 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.
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.
Max.
Re: Uninstalling Subversion
Posted by Kip Warner <Ki...@TheVertigo.com>.
On Sat, 2006-05-08 at 22:51 +0100, Max Bowsher wrote:
> Kip Warner wrote:
> > I checked the mailing list, and unless I am mistaken, there is no
> > uninstall target in the makefile...
>
> Indeed. An 'uninstall' target is far from standard.
>
> > I would like to uninstall Subversion when 1.4 moves from branch to tag
> > officially, but I can't seem to do this? There are too many files to
> > track manually.
>
> That's a matter of opinion, but there are quite a few, yes.
> On the other hand, searching for filenames containing 'svn' or
> 'subversion' gets you most (all?) of them.
>
> > I configured and built it myself, so it isn't as simple as using apt or
> > rpm.
> >
> > Is there some script or some way of removing it?
>
> Delete all the files manually.
>
> > If not, this should surely be noted first in the INSTALL before
> > people even begin to compile.
>
> Why do you think so? This is hardly a matter in which Subversion is
> exceptional. Rather, it is the common case for source installations.
>
> Max.
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. 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. Having no efficient way to remove it is dangerous. Moreover, I
am not the first person to have made note of this on the mailing list.
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.
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.
--
Kip Warner
Vertigo
http://TheVertigo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Uninstalling Subversion
Posted by Max Bowsher <ma...@ukf.net>.
Kip Warner wrote:
> I checked the mailing list, and unless I am mistaken, there is no
> uninstall target in the makefile...
Indeed. An 'uninstall' target is far from standard.
> I would like to uninstall Subversion when 1.4 moves from branch to tag
> officially, but I can't seem to do this? There are too many files to
> track manually.
That's a matter of opinion, but there are quite a few, yes.
On the other hand, searching for filenames containing 'svn' or
'subversion' gets you most (all?) of them.
> I configured and built it myself, so it isn't as simple as using apt or
> rpm.
>
> Is there some script or some way of removing it?
Delete all the files manually.
> If not, this should surely be noted first in the INSTALL before
> people even begin to compile.
Why do you think so? This is hardly a matter in which Subversion is
exceptional. Rather, it is the common case for source installations.
Max.