[ros-users] 'stackless' packages

[Ken Conley]

Hi Patrick,

Thanks for your thoughts.  We are planning to address this with unary stacks.

A lot has been said back and forth about relationships to debian
packages, how stacks evidence themselves in the runtime system, etc...
and I think it's worth clarifying the intent of stacks.

Stacks != collection of packages

Stacks = installation information for code

This is, intentionally, stacks do not evidence themselves in the
runtime system, and, similarly, packages do not evidence themselves in
the installation system.  This maintains a separation of concerns.

Ideally, stacks exist at the boundary of coupling between various
libraries.  This is related to our commitment to maintain
backwards-compatibility between releases.  If several packages are
grouped in a package together, then they can move their coupled APIs
together in lockstep.  If they exist in separate, installable units,
one may have to take additional steps to make these API modifications
as you increase the configuration space of the install (i.e. a user
may install the update for one library, but not the other).

Finally, the debians are not the reason that stacks exist, they are
merely a by-product of releasing a stack.  The release of a stack
actually kills many birds with one stone:

 * It creates a versioned source tarball of the stack
 * It records information about which version of a stack works with
which ROS distribution
 * It provides information about how the source control for the code
is organized (branches/tags/etc...)

This information is consumed by multiple systems:

 * our documentation infrastructure
 * our indexing infrastructure
 * our debian build system
 * our continuous integration (testing) infrastructure
 * rosinstall/roslocate

In the future, this would hopefully feed into other build
infrastructures, like macports, yum, etc...

regards,
Ken


On Wed, Feb 9, 2011 at 11:32 AM, Patrick Bouffard
<bouffard at eecs.berkeley.edu> wrote:
> I have a slight sense of deja-vu posting this so apologies if this has
> already been discussed at length--though if so, I wasn't able to find
> it (looking forward to the stackoverflow-type answers system.. :)
>
> I'm planning to do some restructuring of the packages and stacks in
> starmac-ros-pkg in order to fix what I like to call my "Bug #1" [1].
> At the moment there are two main offenders: packages dealing with the
> AscTec Pelican hardware and packages dealing with the Kinect. I don't
> want these to be mixed in with the starmac_flyer stack, which should
> ideally be completely hardware-setup agnostic and only contain core
> stuff common to flying any quadrotor with any sort of additional
> sensing.
>
> The thing is, in doing this I keep coming to the point where I am
> faced with creating new stacks that have only one package in them,
> which makes me wonder whether the stack is really needed at all. Near
> as I can tell, stacks don't really 'exist' at runtime, as far as ROS
> is concerned. That is, at runtime, either in launch files or at the
> rosrun commandline, only packages are ever referred to, not stacks. In
> fact even at compile time, package names come up a lot, in C++
> #include and Python import statements, but I can't think of a case
> where one has to refer to a stack. The only time I ever refer to a
> stack by name is as an argument to rosmake, and then it's really just
> shorthand for "rosmake package_a package_b package_c", where those
> packages are the ones that are contained in the specified stack.
> Perhaps there are other cases that I just haven't come across, if so
> I'm sure someone will point this out..
>
> But otherwise, is it therefore fair to say that stacks are purely a
> means of collecting packages together? I understand that in general
> the rule of thumb is that when debian packages are built, they
> correspond 1:1 to ROS stacks. But is that actually a necessity or just
> convention? Either way, does it matter if I don't have immediate plans
> to make debian packages?
>
> So it seems to me that there may be some cases where it doesn't make
> sense to place a package within a stack at all. For example, I might
> have a 'starmac_kinect' package, which one would only want to install
> if using a kinect. I might also have, say, 'starmac_hokuyo' which
> would have some functional similarity to starmac_kinect, but one would
> also only want to install when using a Hokuyo LRF. Putting them
> together in a stack would imply that they would always be installed
> together and this would be problematic since such a stack (say
> 'starmac_sensors') would then have to depend on the union of the
> stacks needed for both of the packages.
>
> What would seem more sensible to me is to keep the starmac_kinect and
> starmac_hokuyo packages together in a 'starmac_sensors' directory, but
> not make that directory a stack.
>
> Another similar problem occurs in what is now the 'starmac_demos'
> stack -- as we add more demos, the dependencies of that stack will
> grow to include the union of all the stack dependencies of all the
> enclosed packages--which doesn't make sense as usually one will only
> be interested in particular demo, not all of them (and all their
> dependencies)!
>
> So my question is what are the downsides, if any, with the stackless
> package approach I've described?
>
> Thanks,
> Pat
>
> [1] https://bugs.launchpad.net/starmac-ros-pkg/+bug/706079
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>