On 08/10/2012 03:52 PM, Ewan Mellor wrote:
-----Original Message-----
From: Robert Schweikert [mailto:rjsch...@suse.com]
Sent: 10 August 2012 05:35
To: cloudstack-dev@incubator.apache.org
Subject: Re: Build systems [was RE: [DISCUSS] Binaries (jars) in our source
tree/source releases.]
On 08/09/2012 09:06 PM, David Nalley wrote:
On Thu, Aug 9, 2012 at 8:47 PM, Ewan Mellor <ewan.mel...@eu.citrix.com>
wrote:
-----Original Message-----
From: Robert Schweikert [mailto:rjsch...@suse.com]
[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?
Yup,
OK, so concerns reflected. What are we going to do? It sounds like we should:
Nope, not quite
1. Have a script that packages the source into a tarball
1. Have the build system produce a tarball of build artifacts.
We want to package the source as a tarball, not the artifacts (see my 1.
above). $tool, from David's message, compiles the code into .jar, .war,
.whatever. In this step the binaries are placed within the source tree
or in a created directory of our choosing relative to the source tree.
$tool has an install option that honors $DESTDIR and than places the
binaries into the appropriate directories under $DESTDIR. Any
directories missing in $DESTDIR get created by $tool
This approach works for both packagers and "install from source" users.
For "install from source" users $DESTDIR is set to /
2. Have a separate script that takes the tarball and a spec file and runs
rpmbuild to produce an RPM.
3. Ditto for .deb.
4. Have Jenkins run those scripts, so that we have RPMs and .debs for every
build.
5. Expect that the distros are going to ignore our packages and make their own.
Is that the summary of it?
Yes, with the exception on point 1 as noted above.
Robert
--
Robert Schweikert MAY THE SOURCE BE WITH YOU
SUSE-IBM Software Integration Center LINUX
Tech Lead
rjsch...@suse.com
rschw...@ca.ibm.com
781-464-8147
