+1 - this makes the most sense to me. It might take a little more effort, but a seamless result would be well worth it IMHO.
On Oct 17, 2012, at 10:13 AM, David Nalley <da...@gnsa.us> wrote: > On Wed, Oct 17, 2012 at 12:50 PM, Edison Su <edison...@citrix.com> wrote: >> >> >>> -----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. > > > Personal opinion here. > I think both approaches are good, but not ideal. > Ideally in my mind - maven install (or some similar profile) would > actually deploy the software to the machine you are on. Configurable > arguments for things like bindir, sysconfdir, and prefix (default > being /) (and perhaps on a per-project basis). And that should become > the default way for developers to deploy CloudStack (with a remote > option that pushes software to a remote machine/devcloud) > Having different install/deploy methods for developers and users is > fail - everyone should be using the same thing - which will eliminate > many of the differences. > Packaging tools like rpmbuild/dpkg should call something like mvn > install -Dprefix=%{buildroot} and be able to walk away with packages > that would deliver something nearly identical (but better, because > it's a package) as running mvn install on a machine. > > Thoughts, comments, flames? > > --David > Stratosec - Secure Infrastructure as a Service o: 415.315.9385 @johnlkinsella
