Return-Path: X-Original-To: apmail-incubator-cloudstack-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-cloudstack-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id EC836DFCF for ; Wed, 17 Oct 2012 21:28:16 +0000 (UTC) Received: (qmail 9775 invoked by uid 500); 17 Oct 2012 21:28:16 -0000 Delivered-To: apmail-incubator-cloudstack-dev-archive@incubator.apache.org Received: (qmail 9704 invoked by uid 500); 17 Oct 2012 21:28:16 -0000 Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: cloudstack-dev@incubator.apache.org Delivered-To: mailing list cloudstack-dev@incubator.apache.org Received: (qmail 9696 invoked by uid 99); 17 Oct 2012 21:28:16 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 17 Oct 2012 21:28:16 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of noa@spotify.com designates 209.85.223.175 as permitted sender) Received: from [209.85.223.175] (HELO mail-ie0-f175.google.com) (209.85.223.175) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 17 Oct 2012 21:28:09 +0000 Received: by mail-ie0-f175.google.com with SMTP id c13so12563928ieb.6 for ; Wed, 17 Oct 2012 14:27:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=NZLAP6BMt5a0CDzE5k32voYWx+Vh4SQBi0HNPYDDhXs=; b=n98R0dAq/oteH/Ui++cjmTQjWNfj2WAWHLsqDOVS+C52wQp2ZYwgkqfxHAxBXehCNs V6IPVA7IOJv/JbWZVi9971onCqu/X3fXusa+x+QFHLu1iD30MBtpqq4/bGrNHE7q7j5L 8hvy+gtX73CH6W8Xp8N0l1dOob9xZCtuXHGFyy9yGRTq4ACmSVlRBK3bWMJog8SkcAxw 5g6nA7bLywaAjNC2Wgb10x5qyLgoCe6x8olRTXWXWM45Xb1lJqEALkNHxGJGvLSsNLiv 1KeJBY0Hx4KyUtxuWXFc9OB+RYU+g6Xuy4diEf5TEl7qqwNmJo0XunytBq1B915k32sT Enww== MIME-Version: 1.0 Received: by 10.50.47.201 with SMTP id f9mr2910478ign.44.1350509267908; Wed, 17 Oct 2012 14:27:47 -0700 (PDT) Received: by 10.42.137.7 with HTTP; Wed, 17 Oct 2012 14:27:47 -0700 (PDT) In-Reply-To: References: <507E754C.2000901@widodh.nl> Date: Wed, 17 Oct 2012 23:27:47 +0200 Message-ID: Subject: Re: what is the plan for the build system? From: Noa Resare To: cloudstack-dev@incubator.apache.org Content-Type: multipart/alternative; boundary=14dae9340e172df9b104cc47f169 X-Gm-Message-State: ALoCoQl5IF6FdltEbT0Pwqhma+4wKKHJ75vYJ9JRoqCnlKvmaFVPjF5fIt9TT3fXlROvp+MRw9tW X-Virus-Checked: Checked by ClamAV on apache.org --14dae9340e172df9b104cc47f169 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Oct 17, 2012 at 7:13 PM, David Nalley 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 --14dae9340e172df9b104cc47f169--