On Fri, Feb 19, 2010 at 11:03:34AM -0500, Jason Guiditta wrote:
On Thu, Feb 18, 2010 at 4:27 PM, Mohammed Morsi mmorsi@redhat.com wrote:
Attached is my first take at the aggregator rpm spec. The spec is much cleaner, what is there is only what is needed, and I split the codebase into two packages, the main package containing the standalone aggregator application, and a 'httpd' subpackage (thinking of changing the name to 'daemons' or something) which provides the config / scripts needed to get the services up and running.
It's a working copy, everything looks to be in place, but more dependencies need to be added and I am in the process of testing it out.
-Mo
Does look much cleaner than the old portal one. Couple questions/suggestions:
- I was talking to scott the other day about this, what would everyone
think of not having the services default to on? Couple reasons for this: ** First, an admin may want to do some configuration before starting it up and making it available ** A developer may want to install the rpm just to get all the deps (which some do now). Having to then kill the service (even though it may be just the first time) is an extra step for them
ACK. Seems to me that having them default to 'on' is a relic from the appliance days.
- I think we should probably make the version 0.0.2, since the old
portal rpm was 0.0.1 and substantial changes will be in this one (as well as showing it is currently in synch with api changes)
- Another thought I had (which we briefly discussed) was to keep the
test stuff in it's own package. I don't know if -devel or -debug would be proper naming, but it seems silly to me to require all the test libraries we depend on (some of which are yet to be packaged) for the production deployment/rpm. If someone wants to test their rpm install, I think it would be nice to still be able to use yum, but I like the direction you have taken of minimizing deps in the main package and I think this would be in keeping with that.
- We no longer use the render_component plugin, just in case that has
any effect on your spec. If it does, we could just remove it before you finalize the spec.
-j _______________________________________________ deltacloud-devel mailing list deltacloud-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/deltacloud-devel