incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noa Resare <...@spotify.com>
Subject Re: what is the plan for the build system?
Date Wed, 17 Oct 2012 21:27:47 GMT
On Wed, Oct 17, 2012 at 7:13 PM, David Nalley <david@gnsa.us> wrote:

>
> 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?
>
>
There are a lot of different ways to do software deployment. Some people
prefer to distribute tarballs of sources, some people prefer to build
everything out of a ports system. To me, binary software distributions via
a package system brings a lot of advantages, for example:

* repository infrastructure with checksum and signature validation
* checksums of installed files
* standardized version management
* a streamlined uninstall process
* the ability to make different pieces of software conform to a standard
set of behavior expectations based on the policy of the OS distribution

Fortunately we don't have to choose. We can all improve our favorite
mechanism for software distribution and in the end everyone wins.

/noa

-- 
Developer, Engineering Experience, Spotify

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message