incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Nalley <>
Subject Re: Build systems [was RE: [DISCUSS] Binaries (jars) in our source tree/source releases.]
Date Fri, 10 Aug 2012 01:06:09 GMT
On Thu, Aug 9, 2012 at 8:47 PM, Ewan Mellor <> wrote:
>> -----Original Message-----
>> From: Robert Schweikert []
>> [Snip]
>> > * We want to be able to package CloudStack in RPMs and .debs that
>> correctly depend on packages available on the target platform.
>> This is IMHO not a "job" of the project. This is up to the packagers
>> and
>> package maintainers for the various distros. I will maintain openSUSE
>> and SLE builds in OBS and would very much prefer that the build system
>> know nothing about how to build an rpm. We should maintain a "reference
>> spec file" in the source tree and I will contribute to that, but having
>> the build system crank out a .deb or .rpm package is just not the best
>> approach.
> David, could you reply to this?  You generally have opinions on how packages should be
built.  I happen to disagree with the comment above, but I'm not a packager so there's a strong
chance that I haven't got a clue what I'm talking about, and so I will do whatever people
want in this regard.

So I think this is a terminology issue, perhaps.
My perspective (with packager hat on)
So assuming we pick $tool to replace ant. I tend to agree - $tool
should not build RPMs or .debs.
There are tools to build RPMs and .debs - (rpmbuild and dpkg) and they
should build the packages. They will call $tool to actually build the
software, but we ought not get into the loop of $tool calling
rpmbuild/dpkg calling $tool.
Also - $tool should have an option for turning dependency resolution
off. (Maven certainly has this, and I am sure other tools do as well.)
Packagers don't want dependency resolution - the guidelines they
operate under don't permit bundled or automagically downloaded
dependencies. Instead those need to be packaged independently and
listed as a requirement (or build requirement) for the package. Any
sane $tool will handle this.

This doesn't mean that we wouldn't/couldn't automate RPM/deb builds in
something like jenkins. We just don't want another debacle like waf.
Those packages typically will not be as good as distro-maintained
packages in my experience. The distro also won't be kicking out RPMs
for every iteration either, so it's a mixed bag.

Robert, does this adequately reflect the concerns?


View raw message