cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noa Resare <>
Subject Re: what is the plan for the build system?
Date Wed, 17 Oct 2012 15:15:04 GMT
On Wed, Oct 17, 2012 at 11:07 AM, Wido den Hollander <> wrote:

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

I think that is perfectly reasonable. If we determine that it is a viable
solution to backport what is needed to Debian Squeeze I will do my best to
convince my organization to make those packages available to the community.

>  * 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.
I agree that having debian/rules call maven that in turn builds the
packages would be the cleanest way.

>  * 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?
Yes, I think it makes much sense. The argument against depending on jars
shipped by the distribution mostly holds true in an environment where disk
is very cheap, and the cost of the unintended side effects of updating
specific dependencies are expensive.

For sensible stable distributions (debian stable, ubuntu LTS etc) this is a
small problem, but in organizations where a set of backports of newer
library packages are maintained, you might be in for a bad surprise if
someone backports a new release of some library that many different systems
depend upon. Being able to test each toplevel piece of software as a
codebase plus a specific set of dependencies that doesn't change until next
release simplifies release management and change management a lot.


Developer, Engineering Experience, Spotify

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message