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:
1. Use one master spec that goes "ros-groovy"
2. 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
[1] https://github.com/ros-infrastructure/bloom
_______________________________________________
robotics mailing list
robotics@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/robotics
