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
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 * 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
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
On 02/19/2010 11:03 AM, Jason Guiditta wrote:
On Thu, Feb 18, 2010 at 4:27 PM, Mohammed Morsimmorsi@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
Agree on this, was reluctant to bring this over in the first place, but did anyways as I wasn't sure if we needed it, even though it's a good idea not to start a service by default according to the packaging guidelines
http://fedoraproject.org/wiki/Packaging/SysVInitScript#Why_don.27t_we....
Removed the bits doing so (though chkconfig / service is still needed to register the init scripts on install). I also renamed the package to daemons as it contains the dependencies and config for mongel, taskomatic, http, etc.
- 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)
Done
- 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.
Created a separate 'doc' subpackage, containing the current contents of the src/doc directory and the src/test directory. Unfortunately I don't think is possible to have a main package own an entire directory and have a subpackage in the same spec only a couple subdirectories (anyone correct me if I'm wrong, every time I try the main package ends up having all the subpackage files which would cause conflict on installation). Thus I split out the documentation into its own %{doc_root} dir which ends up in /usr/share/deltacloud-aggregator-doc (similar to what we had in ovirt, though that was its own seperate package/spec completely)
- 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
I don't think it changes the spec, so no worries.
Attached is the most recent spec and srpm. Most everything should be done, save one major thing, the rubygem dependencies list (I'm not sure what they all are, could someone fill me or the spec itself in). Also optionally we could add a %check section to run the test suite to make sure everything works on build/install.
-Mo
deltacloud-devel@lists.fedorahosted.org
-
jason.guiditta -
Mo Morsi -
steve linabery