Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <507E754C.2000901@widodh.nl>
Date: Wed, 17 Oct 2012 11:07:24 +0200
From: Wido den Hollander <wido@widodh.nl>
User-Agent: Mozilla/5.0 (X11; Linux i686;
 rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: cloudstack-dev@incubator.apache.org
Subject: Re: what is the plan for the build system?
References: 
 <CANc7MVxN=Qt7_N2trG9rc2AcCFGxewBpaad3Ho6Oh=_PgE+OdA@mail.gmail.com>
In-Reply-To: 
 <CANc7MVxN=Qt7_N2trG9rc2AcCFGxewBpaad3Ho6Oh=_PgE+OdA@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

On 16-10-12 10:45, Noa Resare wrote:
> Hello friends,
>
> I've been tasked with looking into the possibility of running cloudstack on
> Debian stable, and based on my preliminary investigations I have a few
> questions that I hope that someone can answer.
>

I've been trying the same, but I gave up. Debian stable is far behind at 
this point with the packages, for example libvirt is version 0.8.3, 
while CloudStack currently requires 0.9.4 at least.

The work I done on the Debian packages makes sure they work on Ubuntu 
12.04 and on Debian Unstable.

> * What is the long term plan for the build system? Right now we use Make
> (debian/rules), waf, maven and ant and that setup doesn't exactly lend
> itself to a gentle learning curve. Also, it builds everything (at least)
> twice.
>

This hasn't been decided yet in total, but my idea would be (deb):

* dpkg (debian/rules) calls maven with sbindir, sysconfdir args, etc
* maven outputs a completely build tree in build/usr/sbin, 
build/etc/cloud, etc, etc
* dpkg then fetches the files from build/* into the required packages.

> * Using maven for populating the deps directory, with repositories and
> transitive dependencies has a bad habit of breaking in surprising ways.
> Since third party pom files can inject repository references to
> repositories that returns bad data it's a fragile process. I'd like to
> spend some time improving this, and there are a few ways of doing it, none
> of which is obviously the right way to go. Where would I ideally direct my
> efforts?
>
> * There are some dependencies to specific versions of some java
> dependencies not available in Debian squeeze (commons-codec, log4j). What
> is the rationale for adding those as dependencies instead of pulling the
> exact version that we want via maven, since we are downloading >100M of
> dependencies anyway?
>

I wanted to keep the packages as small (in size) as possible. As a 
package maintainer/build I also think that you shouldn't package what 
the repository from that distribution is already providing.

It could conflict with already installed packages. That could be 
resolved by prefixing it with cloud-, but that would be wasting space.

Somebody might want to run their CloudStack hypervisor from a small (4G, 
8G) flash-drive or just in memory. Size does matter there.

I don't like packaging anything redundantly, so that's why we have the 
dependency on external packages.

What we could do for supporting older distributions is backporting some 
parts or supplying it ourselfs, with dpkg (and probably rpm) you can 
depend on package A or B, so we could have:
* libjava-commons-codec
* cloud-libcommons-codec

Our packages could depend on either one of those.

In my opinion it would be very hard to get CloudStack Debian Stable.

The main problem is that CloudStack is a fast evolving project and we 
are going to do our first release under ASF.

We have now decided that we will support Ubuntu 12.04 and RHEL 6.3 and 
going forward from that.

I think we should keep supporting Ubuntu 12.04 at least until 14.04 
(next LTS) comes out, users need stability in this.

Does this make any sense?

Wido