On 06/15/2013 11:44 PM, Ankur Sinha wrote:
On Sat, 2013-06-08 at 15:22 -0400, Rich Mattes wrote:
I'll be trying to do some review swaps on -devel in the coming days to get things moving.
Hi Rich,
I'll have a few more cycles to work on these once the elections finish next week.
I had another brain fart on packaging groovy up, in a manner similar to how the texlive[1] (the spec is scary, please view at your own risk!) package is done:
- Use one master spec that goes "ros-groovy"
- Checkout the entire source via wstool and build it in the spec as
detailed[2] 3. Figure out BRs and add them to spec: can be done from manifests 4. Figure out Requires and add them to the sub-packages: can be done from the manifests. 5. Put all files for the stacks/packages into sub-packages: ros-groovy-<stack>
All the core utils can be packaged separately like you've done them already.
Jindrich wrote a C program[3] iirc that went over the source tree and spewed out a spec. If required, we could do that too. The info required to build this stuff is mostly in the manifests. A simple xml parser program should be enough if we think of scripting it up.
I think we might be better off trying to extend the upstream "bloom" tool[1]. It's already got the logic to parse the xml files and pull out the build requirements, and they're using it upstream to spit out the control files for their deb files. It's pluggable, and it probably wouldn't be that hard to add a spec file generator along side their debian generator (which is located in the source at bloom/generators)
The advantage here is that it'll be built as documented which should be comparatively easy, and all at once. The disadvantage is that an update to any of the modules will require a complete rebuild. This is bad on the build side only. With delta rpm, users won't (shouldn't) get any updates to the unchanged sub packages.
I've been meaning to try this out. Just haven't found the cycles :/
I'm in the same boat. I'm trying to focus most of my time on trying to get the fuerte base finished up (and other miscellaneous bugfixes to my packages). But in the long run
Even if we deploy it in /opt, we can still host a repos.fedoraproject.org repo owned by the robotics group.
That wouldn't be a bad idea. We might also be able to request group privileges for the copr repositories as well. I think once the fuerte packages are in we can try to explore infrastructure for packages that land in /opt
Rich