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