> -----Original Message----- > From: Noa Resare [mailto:n...@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 <w...@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
