[ros-users] clarifying package installation 'best practices'?

Wed Mar 4 21:42:05 UTC 2015

Docker is workable for a deployed/industrial scenario, but it's more
problematic for a research platform, where you're in all the time making
updates and rebuilding your workspace, etc, particularly when ROS maps to
random ports and docker requires ports to be explicitly exported. In a
fully deployed scenario, though, it makes more sense to treat the entire
filesystem as an atomic unit, whether distributed as an image, and overlay,
or even just a squashfs. (Has anyone built any tooling to create an
Ubuntu+ROS squashfs? I'd be interested to play with such a thing and see it
in action...)

Our setup at present is mostly defined in a big templated debian-installer
preseed file, but we're experimenting with Ansible, and I know others have
created ROS configurations in puppet and vagrant.

In any case, the business of how you get there is somewhat orthogonal to
the issue of what the user sees when they first log in, and how we
communicate to them (via the wiki and other means) when to install a
package from deb vs. from source, which you should prefer, and how and why
you'd switch between them.

It seemed there was sufficient interest, so I went ahead and created a
vendor SIG— please feel free to join and continue the discussion there:
https://groups.google.com/forum/#!forum/ros-sig-vendors

On 4 March 2015 at 15:08, Ryan Hass <ryan at invalidchecksum.net> wrote:

> Mike,
>
> I think this is where the Docker, and the Chef solutions fit in well. At
> the core of the problem, you are effectively describing a configuration
> management issue. Docker makes it easy to ship a pre-built and
> pre-configured set of things -- and the Chef solution allows to abstract
> the process into a DSL. They both have their pros and cons, but I think
> they are not mutually exclusive either. I am very interested in this
> discussion, so if you have a private thread going please loop me in!
>
> -Ryan H.
>
> On Wed, Mar 4, 2015 at 5:19 AM, Mike Purvis <mpurvis at clearpathrobotics.com
> > wrote:
>
>> As an OEM who ships a lot of robots to first-time ROS users, one of the
>> things I/we have thought about at Clearpath is exactly how to configure the
>> robots for the best combination of ease-of-production on our side,
>> ease-of-getting-started on the user's side, and ease-of-maintenance on the
>> user's side. The current state of affairs is:
>>
>>    - Everything on the robots is installed from debs, from a combination
>>    of packages.ros.org (buildfarm) and packages.clearpathrobotics.com
>>    (in-house buildbot-ros builds).
>>    - An /etc/ros/setup.bash file falls through to
>>    /opt/ros/indigo/setup.bash. This is what is sourced for the robot_upstart
>>    job which brings up the base software.
>>    - The homedir is populated with a README file explaining how to
>>    create a workspace with a new package in it...
>>    - ... and further how to change that "master" setup.bash, in the
>>    event that your new package contains nodelets, plugins, or things you want
>>    to launch as part of the robot_upstart background job.
>>    - Because all the "system" software is installed from debs, upgrading
>>    is a fairly sane update/dist-upgrade story.
>>    - But, if there's a repo of special customization
>>    launchers/URDF/whatever that's specific to that one platform, it is
>>    configured as a package and placed in a source workspace in the homedir.
>>    - The desktop and simulator software is also distributed as debs, and
>>    so provide a sane story for getting started on the user's supporting
>>    computer (but if the user wants the meshes or other stuff from a
>>    customization package, it must be manually copied over, le sigh).
>>
>> We also resell a number of other vendors' products, and many do not make
>> it any farther than a source workspace for everything— often with a manual
>> apt-get step for dependencies (rather than using rosdep). On the one hand,
>> this is perhaps easier for hacking on and exploring the platform's own
>> software, but it sucks for pretty much everything else.
>>
>> Anyhow, if anyone's interested in these issues or has thoughts about how
>> to improve the state of affairs for OEMs or users of OEM robots, please get
>> in touch off-list, would love to discuss further; at some point we could
>> also consider establishing a SIG for vendors. In any case, I can be found
>> at mpurvis at clearpathrobotics.com
>>
>> M.
>>
>> On 4 March 2015 at 07:42, Jonathan Bohren <jonathan.bohren at gmail.com>
>> wrote:
>>
>>> I think this is a great idea. I can't say the likelihood that this gets
>>> added to the wiki, but I'd be happy to accept a PR to add this to
>>> http://rosindex.github.io
>>>
>>> https://github.com/rosindex/rosindex/issues/142
>>>
>>> -j
>>>
>>> On Wed, Mar 4, 2015, 03:44 G.A. vd. Hoorn - 3ME <
>>> g.a.vanderhoorn at tudelft.nl> wrote:
>>>
>>>> All,
>>>>
>>>>
>>>> just wondering whether we should somehow clarify what the current 'best
>>>> practices' are for installing packages onto a ROS pc. I see a lot of
>>>> people that assume that building from source (after cloning from a
>>>> repository) is _the_ way to do things.
>>>>
>>>> Apart from the fact that this is essentially a waste of time and effort,
>>>> it also often leads to problems (as they forget to check for and / or
>>>> install all dependencies first), which then results in numerous ROS
>>>> Answers questions. Having the sources locally also seems to invite some
>>>> users to start editing / hard coding parameters (such as IPs / serial
>>>> ports) into nodes, which is obviously unwanted.
>>>>
>>>> Somehow I have a feeling that the prominent placing of the repository
>>>> URL in the Package Summary contributes to the confusion.
>>>>
>>>> Would it perhaps be an idea to add a one-liner to the 'Package Summary'
>>>> on wiki pages of released packages that shows users how to install it
>>>> ("Installation: sudo apt-get install ros-$release-pkg-name", although
>>>> that is distribution specific)? Or a link to a (new) wiki page that
>>>> explains how to install packages in general (with the from-source option
>>>> shown last)?
>>>>
>>>>
>>>> Gijs
>>>> _______________________________________________
>>>> ros-users mailing list
>>>> ros-users at lists.ros.org
>>>> http://lists.ros.org/mailman/listinfo/ros-users
>>>>
>>>
>>> _______________________________________________
>>> ros-users mailing list
>>> ros-users at lists.ros.org
>>> http://lists.ros.org/mailman/listinfo/ros-users
>>>
>>>
>>
>> _______________________________________________
>> ros-users mailing list
>> ros-users at lists.ros.org
>> http://lists.ros.org/mailman/listinfo/ros-users
>>
>>
>
> _______________________________________________
> ros-users mailing list
> ros-users at lists.ros.org
> http://lists.ros.org/mailman/listinfo/ros-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20150304/23b611e3/attachment.html>