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

[Ryan Hass]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20150304/707cf1c8/attachment.html>