> -----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: 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. 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.
