On 08/10/2012 09:52 PM, Ewan Mellor wrote:
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:
1. Have the build system produce a tarball of build artifacts.
2. Have a separate script that takes the tarball and a spec file and runs
rpmbuild to produce an RPM.
3. Ditto for .deb.
No need for deb, that's where the debian/rules file is for.
You should be able to just run:
$ dpkg-buildpackage
That will call debian/rules which can then execute the scripts which
compiles and generates the artifacts.
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?
Ewan.
