[ros-users] 'stackless' packages
bouffard at eecs.berkeley.edu
Wed Feb 9 20:12:36 UTC 2011
On Wed, Feb 9, 2011 at 11:52 AM, Jack O'Quin <jack.oquin at gmail.com> wrote:
> On Wed, Feb 9, 2011 at 1:32 PM, 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" .
>> 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
>> 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.
Understood. But if I have no plans to make use of the debbuild system,
why should that be an issue for me?
>> 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
>> 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.
Yes, there is also that problem, but the ones I mentioned are more
troublesome to me.
> There is a proposal for "unary" stack support in ROS. I would love to
> see some form of that implemented for E-turtle.
I guess you're referring to this thread:
Sounds like a good initiative, and though I don't see how it can help
me at the moment, it's certainly something to keep an eye on.
I appreciate that there can be some advantages to using stacks but I
still don't really see them as applicable in the case I'm describing.
It also seems that it is easy enough to put packages into stacks later
on, if and when stacks make more sense than they do now.
> ros-users mailing list
> ros-users at code.ros.org
More information about the ros-users