incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Schweikert <rjsch...@suse.com>
Subject Re: Build systems [was RE: [DISCUSS] Binaries (jars) in our source tree/source releases.]
Date Fri, 10 Aug 2012 12:34:33 GMT
On 08/09/2012 09:06 PM, David Nalley wrote:
> On Thu, Aug 9, 2012 at 8:47 PM, Ewan Mellor <Ewan.Mellor@eu.citrix.com> wrote:
>>> -----Original Message-----
>>> From: Robert Schweikert [mailto:rjschwei@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,

Thanks,
Robert



-- 
Robert Schweikert                           MAY THE SOURCE BE WITH YOU
SUSE-IBM Software Integration Center                   LINUX
Tech Lead
rjschwei@suse.com
rschweik@ca.ibm.com
781-464-8147

Mime
View raw message