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