Thanks for the detailed answers. More comments inlined.
On Tue, Feb 09, 2010 at 11:55:58AM -0600, Garrett Holmstrom wrote:
On Mon, Feb 8, 2010 at 5:29 PM, graziano obertelli
> As mentioned before, we already have a spec file, which produces packages
> not good enough to be integrated in Fedora, but this will give us a head
> start to flushing out the installation procedure on Fedora as well as
> finding how to configure it properly. I would love for comments on how to
> make things better on Fedora, and in order to do that, we have a source
> tree available on launchpad for 1.6.2. Problem is that, for now, I'll be
> working on a private branch which I'll merge if our Q&A will give the
> green light on the packages: if there is interests in seeing it, I'm more
> than happy to publish it where is convenient for Fedora. Is there interest
> for it? Is there a preference of where to put the code?
> Also, if someone is working on axis2c, axis2 and/or rampartc, I'll be more
> than happy to use those packages too.
Before you release 1.6.2, please fix the download URL in the spec
file, which currently leads to a 404 on a domain parking page. If you
don't plan on making the one that's already there work, perhaps you
changed! I'll have to double check for the release candidate.
Here are some nitpicky packaging guideline-related things that stick
out to me:
* Download URL is incorrect (see comments above)
* Explicit Conflict tags are forbidden by the packaging guidelines
So, the reason's why Conflict is there, is beacause we need all the
eucalyptus pacakges to be the same version. In our testing it happened
that some older versions were left behind, making the experience failry
miserable (failure modes in this case are very frustratring to chase). I
can remove it, but how do I ensure that all eucalyptus pacakges installed
are of the same version?
* Dependencies need to go in separate packages
* Fedora's installing files in /opt is forbidden by FHS (see
We don't have enough time and expertise to package all the dependencies on
their own packages at this time. At the moment we put in /opt axis2c and
rampartc (and axis2 only to compile the package): if I have time I can try
to move them into / by 1.6.2 release time.
* "BuildRequires: java-sdk >= 1.6.0" should be
"BuildRequires: java-devel >= 1:1.6.0"
changed! And I changed the requirement too.
* Should use %configure macro instead of calling configure directly
* configure is also currently called with the wrong prefix
* Should use %_sbindir, %_sysconfdir, %_datadir, etc. instead of hardcoding all
I will work on this.
* The previously-mentioned Xen vs. KVM config issue (Perhaps a
variable at the
top of the spec file (e.g., "%global hypervisor kvm"))
Good idea: added a %define for now. Does %global exists also in CentOS?
* Services should be started/stopped with /sbin/service in %pre
* Custom variables at the top should be defined with "%global"
* Custom variables should not begin with "__"
* Vendor and Icon RPM tags also need to go
* "This package contains walrus" is not a useful
I thought that it was enough :). I changed it.
Hopefully I will have sometime tomorrow and over the weekend to work on
the packaging and writing a better spec file (there are still quite a few
point you mentioned that I have not tackled). Is that ok for me to post
the spec file (once I get something which works) on this list to have more
While I haven't done an in-depth check of things like making sure the
right file types are in the right places and such, hopefully that will
help with getting the spec file cleaned up. I especially recommend
having a look at https://fedoraproject.org/wiki/Packaging:Java
tips on packaging Java programs.
cloud mailing list
Eucalyptus Systems, Inc.
130 Castilian St. Goleta, CA 93117