On Wed, Feb 9, 2011 at 1:32 PM, Patrick Bouffard
<bouffard@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?

It is more than that. The stack is the unit of release and install.
Stacks have versions, packages do not. The debbuild system deals only
with stacks.

> 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?

There are many good reasons to release single-package stacks. The
problem with them right now is that the stack needs a different name
from the package, which is awkward and redundant, but possible.

There is a proposal for "unary" stack support in ROS. I would love to
see some form of that implemented for E-turtle.
-- 
 joq