Thanks Ken. I think your response should be tagged with #stacks,
#packages, #designdecisions, and #guru. :)
Is there more info on what 'unary stacks' will look like, beyond the
one mailing list thread? And do you have a recommendation for my
current quandary? I'm still leaning towards stackless packages, at
least for right now.
Pat
On Wed, Feb 9, 2011 at 1:33 PM, Ken Conley <
kwc@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@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@code.ros.org
>> https://code.ros.org/mailman/listinfo/ros-users
>>
> _______________________________________________
> ros-users mailing list
> ros-users@code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
(text/plain)