catkin uninstall

[Jack O'Quin]

I've been studying the catkin docs lately and looking at some code. 

As best I can tell, it generates code to install a stack, but no way to uninstall it.

I hope there is an uninstall option, and I am just not seeing it.

[Daniel Stonier]

I couldn't find any either - I suspect nobody's had a real need for it yet. Cmake doesn't provide one by default, but it shouldn't be too hard to add. I usually use http://www.cmake.org/Wiki/CMake_FAQ#Can_I_do_.22make_uninstall.22_with_CMake.3F for my projects. Not sure if fancy catkin logic would stop that working at the stack level though. 

[Jack O'Quin]

Thanks for the pointer, Daniel.

After my recent bad experiences with Python easy_install, I consider
an explicit uninstall a requirement for the ROS build system.
Requiring users to have a built source tree in order to make that
happen would be acceptable, IMHO.
--
joq

[Tully Foote]

Hi Jack, 

Like cmake we have avoided setting up the uninstall target mostly because it can fail with both failed removals and extra removals.  Changes to the state of the system between install and uninstall can break things.  For example if you call make install, remove a build target, and make install again, then the removed build target will still be in the installed space, but not in the manifest.txt so it won't be removed.  Likewise there's also potentially a risk of two install targets installing the same file and when one is removed the other installed package will be broken.  

The main way that we work around this when developing is to simply install into project specific paths.  I often use /tmp/test_installation by using the CMAKE_INSTALL_PREFIX at cmake time.  Then the uninstall is simply, rm -rf /tmp/test_installation.  And I don't worry about messing up my system installation from debs.  

Another tool which I have used in the past regularly is checkinstall.  Which will nicely build a debian package of whatever the command does.  

Use it as follows:

sudo checkinstall make install

It will guess and then prompt you for the required debian metadata.  Then you can remove the installation by using dpkg -r packagename.  

Tully

I can't find a good thread with justification but here's one cmake reference: http://www.cmake.org/pipermail/cmake/2004-November/005853.html

--
You received this message because you are subscribed to the Google Groups "ROS Buildsystem Special Interest Group" group.
To post to this group, send email to ros-sig-b...@googlegroups.com.
To unsubscribe from this group, send email to ros-sig-buildsy...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/ros-sig-buildsystem?hl=en.

--
Tully Foote
tfo...@willowgarage.com
(650) 475-2827

[Jack O'Quin]

On Sat, Jul 7, 2012 at 4:55 PM, Tully Foote <tfo...@willowgarage.com> wrote:
> Hi Jack,
>
> Like cmake we have avoided setting up the uninstall target mostly because it
> can fail with both failed removals and extra removals. Changes to the state
> of the system between install and uninstall can break things. For example
> if you call make install, remove a build target, and make install again,
> then the removed build target will still be in the installed space, but not
> in the manifest.txt so it won't be removed. Likewise there's also
> potentially a risk of two install targets installing the same file and when
> one is removed the other installed package will be broken.

I understand that uninstall is difficult. But, I believe it is necessary.

Users could be instructed to save the exact build tree they installed
from for uninstalling.

> The main way that we work around this when developing is to simply install
> into project specific paths. I often use /tmp/test_installation by using
> the CMAKE_INSTALL_PREFIX at cmake time. Then the uninstall is simply, rm
> -rf /tmp/test_installation. And I don't worry about messing up my system
> installation from debs.

The main requirement for uninstall is for end-users. It is not much of
a problem for ROS developers.

> Another tool which I have used in the past regularly is checkinstall. Which
> will nicely build a debian package of whatever the command does.
>
> Use it as follows:
>
> sudo checkinstall make install
>
> It will guess and then prompt you for the required debian metadata. Then
> you can remove the installation by using dpkg -r packagename.

It is mostly in non-Debian systems that users need to isntall ROS from
source. This won't help many of them.

> I can't find a good thread with justification but here's one cmake
> reference: http://www.cmake.org/pipermail/cmake/2004-November/005853.html

This mostly says that it's hard to get right. Which is true in the general case.

It is not so clear that ROS stacks cannot be uninstalled reliably.
They tend to be relatively structured, and are unlikely to install
overlapping files.
--
joq

[Lorenz Mösenlechner]

Hi,

I'm actually against an uninstall target exactly for the reasons Tully
mentioned. An update to CMakeLists.txt can lead to inconsistencies
very easily and an uninstall target might make people trust too much
in that functionality. It is much worse if people believe they cleanly
uninstalled something while fragments were left over than not having
an uninstall target at all. Clean uninstalls should totally be left to
the Linux distro's package management system. If people build from
source I they should either create packages for their distro or
install in temporary directories.

Lorenz

> --
> You received this message because you are subscribed to the Google Groups "ROS Buildsystem Special Interest Group" group.
> To post to this group, send email to ros-sig-b...@googlegroups.com.
> To unsubscribe from this group, send email to ros-sig-buildsy...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/ros-sig-buildsystem?hl=en.
>



--

Lorenz Mösenlechner | moes...@in.tum.de
Technische Universität München | Karlstraße 45
80335 München | Germany
http://ias.cs.tum.edu/ | Tel: +49 (89) 289-26910

[Jack O'Quin]

On Tue, Jul 10, 2012 at 9:48 AM, Lorenz Mösenlechner <moes...@in.tum.de> wrote:

> I'm actually against an uninstall target exactly for the reasons Tully
> mentioned. An update to CMakeLists.txt can lead to inconsistencies
> very easily and an uninstall target might make people trust too much
> in that functionality. It is much worse if people believe they cleanly
> uninstalled something while fragments were left over than not having
> an uninstall target at all.

A proper uninstall implementation will handle this correctly. As
described in Tully's link above, the install_manifest.txt in the build
tree lists the actual files installed. So, new changes to
CMakeLists.txt will not break uninstall as long as the user follows
instructions not to delete the original build tree.

http://www.cmake.org/pipermail/cmake/2004-November/005853.html

It is probably even possible for make install to detect an earlier
installation and delete the previous files before installing the new
version.

The cmake developers' refusal to support uninstall was a cop-out, IMO.
Even stupid, old GNU automake generated uninstall stanzas that worked
most of the time. SCONS has a very elegant install and uninstall
scheme, tracking all dependencies through the build tree from each
installed file back to its individual sources. Cmake should have
stepped up and done a decent built-in uninstall option. But, at least
they left the hooks in for us to do it.

> Clean uninstalls should totally be left to
> the Linux distro's package management system. If people build from
> source I they should either create packages for their distro or
> install in temporary directories.

I am discouraged to see this idea becoming imbedded our new build tools.

There are good reasons why open source projects always produce source
releases that build and work cleanly on a wide range of target
platforms. Producing binary packages for various Linux distributions
or for OSX and Windows is a specialized skill. Without a build farm
doing continuous integration tests, those packages are unlikely to
work reliably. That is why Debian, Ubuntu and Red Hat have thousands
of "developers" continually doing packaging updates.

Some ROS users may attempt to build RPM packages (for example) from
ROS sources. But, no one is going to maintain a yum repository (for
example) well enough that Fedora users can cleanly install and
uninstall a usable set of ROS packages.

Our old rosbuild had significant limitations. But, it *was* possible
to cleanly build and remove source packages. With catkin, that no
longer seems to be true. Starting with Fuerte, many more users are
reporting problems trying to build on non-Ubuntu distributions or
embedded systems. Those are legitimate use cases. The root cause is
that their environment differs so much from that of most core ROS
developers. If more ROS developers worked in those environments, I
feel sure many of those problems would quickly be solved.

Let's agree that our primary product is a source release, usable on a
wide range of platforms. Producing nice Debian packages for a limited
number of Ubuntu distributions is a wonderful help to many users. But,
we should *not* try to solve basic system build and maintenance
operations that way.
--
joq

[Lorenz Mösenlechner]

Hi,

you are right that having a proper uninstall target would be nice. But
I think it needs to work in 100 percent of all use cases. If it's only
half-working, things could get messy much too easy.

It would be interesting which linux distros are used by how many
people. I guess most people are still using Ubuntu on x86 or amd64.
These people wouldn't need an uninstall target. People using RedHat,
Slackware or Debian can use CheckInstall to create packages for their
package manager. So these people won't need an uninstall target
either. Finally, there is Arch linux and Gentoo for which it is very
simple to create build files to integrate in the package manager.

To summarize, I don't object uninstall targets completely. I just
think it's hard to get them right and an uninstall target that is not
working correctly is worse than no uninstall target at all. Since it
is really easy to create packages in most distros I don't think
hacking together an uninstall target in catkin is really worth the
effort.

Lorenz

[Daniel Stonier]

Just thought I'd chime in since I've previously been one of Jack's use cases. That of an embedded developer with no packaging system. 

For those using ubuntu or other packaging system, is having an uninstall step a hindrance in any way? Would they ever actually use it?

For those doing embedded or source builds, an uninstall step can be quite useful.

Also, to address Tully's concerns, I think 

1) Two targets installing the same file - I think this should be avoided anyway (bad practice?). It shouldn't be cmake's job to worry about it.

2) Removing build targets inbetween installing and uninstalling - isn't this a user issue? If you use a tool the wrong way, of course it won't work.

Daniel.

[Jack O'Quin]

On Thu, Jul 12, 2012 at 11:53 AM, Lorenz Mösenlechner
<moes...@in.tum.de> wrote:
> Hi,
>
> you are right that having a proper uninstall target would be nice. But
> I think it needs to work in 100 percent of all use cases. If it's only
> half-working, things could get messy much too easy.

Agreed. It needs to work reliably. Half-working is a disaster. It
should definitely work better than the alternatives, but none of them
will cover 100% of all use cases.

> It would be interesting which linux distros are used by how many
> people. I guess most people are still using Ubuntu on x86 or amd64.
> These people wouldn't need an uninstall target. People using RedHat,
> Slackware or Debian can use CheckInstall to create packages for their
> package manager. So these people won't need an uninstall target
> either. Finally, there is Arch linux and Gentoo for which it is very
> simple to create build files to integrate in the package manager.

Linux is not the only target. Don't forget OSX or embedded systems.

Your checkinstall suggestion is interesting and worth discussing. We
should give it some serious thought.

The last time I tried checkinstall was many years ago. It did not work
very well back then, and I ended up using GNU stow instead. (I was not
very pleased with that, either.) Presumably, checkinstall works better
now. I was surprised to discover there is even recent support for OSX,
but I don't know how mature that is.

Maybe checkinstall is an option. I could imagine recommending that
people building from source always use checkinstall, if it supports
their underlying platform. The main problem is testing that it
actually works on all relevant platforms. If it does not, we are left
with the same problems as a botched uninstall. Users will attempt to
rm some files, probably not do it exactly right, then ask us for help
on answers.ros.org.

With a built-in uninstall, we can write adequate unit tests which only
depend on the build system, itself. The obvious cases of adding and
deleting installed files can certainly be tested that way. That still
seems like a cleaner and more reliable solution to me.

> To summarize, I don't object uninstall targets completely. I just
> think it's hard to get them right and an uninstall target that is not
> working correctly is worse than no uninstall target at all. Since it
> is really easy to create packages in most distros I don't think
> hacking together an uninstall target in catkin is really worth the
> effort.

I am not advocating that we hack together something that works poorly.
I believe any reasonable build system should allow users to install
files and later remove exactly the files they installed.

There are two common problems that arise:

* multiple packages installing the same file

This is typically not a problem with ROS packages. We should create a
Hudson script to verify that it never occurs during any test build.
Note that checkinstall would not handle this problem, either.

* configuration files that the user edits after installation

ROS is relatively free of user-edited config files. The install
targets are typically read-only to normal users anyway. While we will
always have Linux newbies trying to edit files under /opt/ros just
because they can, reasonable practices can be recommended for most
people.

Maybe there is something else I am forgetting at the moment, but this
is really not that difficult.

I don't want to beat this uninstall issue to death. It is not the most
crucial problem with the build system. I believe there are bigger
problems with over-dependence on the underlying package system than
simply uninstalling files.

Regards,
--
joq