incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edison Su <Edison...@citrix.com>
Subject RE: what is the plan for the build system?
Date Wed, 17 Oct 2012 16:50:35 GMT


> -----Original Message-----
> From: Noa Resare [mailto:noa@spotify.com]
> Sent: Wednesday, October 17, 2012 8:15 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: what is the plan for the build system?
> 
> On Wed, Oct 17, 2012 at 11:07 AM, Wido den Hollander <wido@widodh.nl>
> wrote:
> 
> > The work I done on the Debian packages makes sure they work on Ubuntu
> > 12.04 and on Debian Unstable.
> 
> 
> I think that is perfectly reasonable. If we determine that it is a
> viable
> solution to backport what is needed to Debian Squeeze I will do my best
> to
> convince my organization to make those packages available to the
> community.
> 
> 
> >  * What is the long term plan for the build system? Right now we use
> Make
> >> (debian/rules), waf, maven and ant and that setup doesn't exactly
> lend
> >> itself to a gentle learning curve. Also, it builds everything (at
> least)
> >> twice.
> >>
> >>
> > This hasn't been decided yet in total, but my idea would be (deb):
> >
> > * dpkg (debian/rules) calls maven with sbindir, sysconfdir args, etc
> > * maven outputs a completely build tree in build/usr/sbin,
> > build/etc/cloud, etc, etc
> > * dpkg then fetches the files from build/* into the required packages.
> >
> >
> >
> I agree that having debian/rules call maven that in turn builds the
> packages would be the cleanest way.

For RPM build, what Hugo did is that:
1. "maven install" will install everything into target folder under each project
2. write a rpm spec file to pick up artifacts from all of these target folders, e,g: https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=blob;f=packaging/centos63/cloud.spec;h=b0f4046fef53dd302d1cdecd3db97bffb8357000;hb=4b079cd3dd1304272bbeb61b38c2a10c6715203c

Can the same thing be done for deb build? I think this is the cleanest way, rpm/deb build
is decoupled from maven or ant, or whatever java build we will use.


> 
> 
> 
> >  * Using maven for populating the deps directory, with repositories
> and
> >> transitive dependencies has a bad habit of breaking in surprising
> ways.
> >> Since third party pom files can inject repository references to
> >> repositories that returns bad data it's a fragile process. I'd like
> to
> >> spend some time improving this, and there are a few ways of doing it,
> none
> >> of which is obviously the right way to go. Where would I ideally
> direct my
> >> efforts?
> >>
> >> * There are some dependencies to specific versions of some java
> >> dependencies not available in Debian squeeze (commons-codec, log4j).
> What
> >> is the rationale for adding those as dependencies instead of pulling
> the
> >> exact version that we want via maven, since we are downloading >100M
> of
> >> dependencies anyway?
> >>
> >>
> > I wanted to keep the packages as small (in size) as possible. As a
> package
> > maintainer/build I also think that you shouldn't package what the
> > repository from that distribution is already providing.
> >
> > It could conflict with already installed packages. That could be
> resolved
> > by prefixing it with cloud-, but that would be wasting space.
> >
> > Somebody might want to run their CloudStack hypervisor from a small
> (4G,
> > 8G) flash-drive or just in memory. Size does matter there.
> >
> > I don't like packaging anything redundantly, so that's why we have
> the
> > dependency on external packages.
> >
> > What we could do for supporting older distributions is backporting
> some
> > parts or supplying it ourselfs, with dpkg (and probably rpm) you can
> depend
> > on package A or B, so we could have:
> > * libjava-commons-codec
> > * cloud-libcommons-codec
> >
> > Our packages could depend on either one of those.
> >
> > In my opinion it would be very hard to get CloudStack Debian Stable.
> >
> > The main problem is that CloudStack is a fast evolving project and we
> are
> > going to do our first release under ASF.
> >
> > We have now decided that we will support Ubuntu 12.04 and RHEL 6.3
> and
> > going forward from that.
> >
> > I think we should keep supporting Ubuntu 12.04 at least until 14.04
> (next
> > LTS) comes out, users need stability in this.
> >
> > Does this make any sense?
> >
> >
> Yes, I think it makes much sense. The argument against depending on
> jars
> shipped by the distribution mostly holds true in an environment where
> disk
> is very cheap, and the cost of the unintended side effects of updating
> specific dependencies are expensive.
> 
> For sensible stable distributions (debian stable, ubuntu LTS etc) this
> is a
> small problem, but in organizations where a set of backports of newer
> library packages are maintained, you might be in for a bad surprise if
> someone backports a new release of some library that many different
> systems
> depend upon. Being able to test each toplevel piece of software as a
> codebase plus a specific set of dependencies that doesn't change until
> next
> release simplifies release management and change management a lot.
> 
> /noa
> 
> 
> --
> Developer, Engineering Experience, Spotify

Mime
View raw message