[ros-users] 'stackless' packages

Patrick Bouffard bouffard at eecs.berkeley.edu
Thu Feb 10 18:41:56 UTC 2011

On Wed, Feb 9, 2011 at 2:55 PM, Ken Conley <kwc at willowgarage.com> wrote:
> Unary stacks will probably be as simple as having a stack.xml file and
> manifest.xml file in the same directory, but we haven't had a chance
> to spin up a prototype to see what the effect on tools would be.
> Unfortunately I don't have a solution for you now, and I understand
> your pain -- we feel on our side as well.  The ROS stack separation
> was simply too much strain on us in this cycle to put in one more
> thing like this.

Don't get me wrong--it's not that painful a problem on my side! :) I
just want to avoid creating larger problems than the ones I'm solving.

I don't think the fact that unary stacks are not yet implemented is
really an issue for me now--the issue is more my ignorance of what
exactly are all the implications of having packages in stacks or not.

Yesterday, I moved a couple of packages from existing stacks to
directories that don't have stacks, and also renamed them in the

For example,
FROM: starmac_flyer(stack)/flyer_kinect(package)
TO: starmac_sensors(directory)/starmac_kinect(package)

One thing I noticed is that the change doesn't seem to have registered
in the ros.org documentation index.

So is it the case that, without being inside a stack, a package in my
repository will not be indexed on ros.org? If so then that's a very
good reason to use a stack.

As it stands now, my "bug #1" is essentially fixed in that the
extraneous dependencies shouldn't be there anymore. However it seems
like the unwanted side effect is now that the online documentation is
messed up.

The main reason I didn't want to make these new directories (e.g.,
starmac_sensors) into stacks has to do with the stack dependencies, as
I explained earlier. But I'm thinking that perhaps the best compromise
right now is to turn those directories into stacks (is stack.xml all
the indexer requires?) but not to declare any stack dependencies. If I
did this would the indexer be happy? From what you've said so far it
seems like that would be the case so long as I don't try to do a

Thanks for all the help and sorry that I have to throw these questions
at you at such a busy time. When things quiet down a bit one thing
that probably would help is to have some documentation on the indexer,
since a lot of my questions seemed to essentially boil down to things
that the indexer documentation would address.

One more thing--it occurs to me that if it were possible to declare
"optional" (or perhaps "recommended") stack dependencies, then that
would also help in this case. Let me know if this is something I could
ticket for consideration.


> cheers,
> Ken
>> Pat
>> On Wed, Feb 9, 2011 at 1:33 PM, Ken Conley <kwc at willowgarage.com> wrote:
>>> 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
>>> _______________________________________________
>>> ros-users mailing list
>>> ros-users at code.ros.org
>>> https://code.ros.org/mailman/listinfo/ros-users
>> _______________________________________________
>> ros-users mailing list
>> ros-users at code.ros.org
>> https://code.ros.org/mailman/listinfo/ros-users
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users

More information about the ros-users mailing list