incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rohit Yadav <>
Subject RE: Debian packaging progress
Date Mon, 12 Nov 2012 10:10:13 GMT
Hi Wido,

Thanks for sharing, the new packaging idea is better. Keeping the number of packages low would
be great as long as the functionality provided is not affected.
Are we then going to rename the packages as cloudstack-*? Not sure about breaking symlinking,
it would be great for future releases but will affect upgrade scenarios.

Lastly, I want to share an idea to rename all cloudstack dependencies, we used to install
using the cloud-deps pkg, with a cloudstack-deps or cloud-deps prefix so say there is a pkg
axiom.jar preinstalled on a system, won't fail our installation of cloudstack as one of the
pkgs (say cloud-deps) wanted to install the same pkg in the same location. Keep us posted.


From: Wido den Hollander []
Sent: Monday, November 12, 2012 1:54 PM
To: <>
Subject: Debian packaging progress


Last week at ApacheCon Hugo and I discussed the Deb and RPM packaging
following up on the work which was done in the Maven RPM branch.

The RPM packaging now partially works, but it still needs improvement.

We discussed multiple ideas, but we figured it would be best to use the
maven-shade-plugin and create on JAR file for for example the Agent with
all the runtime dependencies in there.

This makes life much easier and also makes sure we have all the deps we

The client/UI goes into one big WAR file which also has it's
dependencies in it for the same reason.

As I'm going offline for about a month I'll be working on this locally
when I have some spare time.

I don't say this is final, but I'll try to push a new branch later on
with the proposed fixes so we can discuss if we like this for our Deb
and RPM packaging.

As far as I can see now we can ditch the cloud-agent-libs,
cloud-agent-deps and cloud-deps packages, but probably also cloud-utils.

We can reduce the number of packages and individual dependencies, so
that should be a bonus.

Other than that I want to prevent us symlinking from /etc to
/usr/share/cloud/management since that breaks all rules regarding

This is just a FYI to let you know I'm working on it.


View raw message