I built the latest from the packaging branch. I think it is shaping up nicely. Some thoughts:
How would you feel with postponing the config directory changes until 4.2? While I agree conceptually that they are an improvement, waiting with them would keep the diff size down, simplifying merge and the focus of stabilization for 4.1 /n On Mon, Feb 4, 2013 at 11:33 AM, Wido den Hollander <w...@widodh.nl> wrote: > On 02/04/2013 07:12 AM, Sudha Ponnaganti wrote: > >> Wanted to check when would this be implemented?? Several QA folks depend >> on the packages and need this working. >> We have been still building using waf but today that is also not working >> as some references are removed. >> >> Is it possible to accelerate this process or leave old way of packaging >> in place till you are done with the new changes >> >> > I fully understand. As I told David, I think the DEB work is about one day > of work, but then again, there is something like $dayjob. > > What might be even tougher is to get the RPM and DEB packages fully > synced. cloudstack-common for example should contain exactly the same files > in the RPM and DEB version, so Hugo and I will have to keep in touch. > > I really want to have the DEB packaging working this week, period. > > Wido > > > Thanks >> /sudha >> >> -----Original Message----- >> From: rohityada...@gmail.com [mailto:rohityada...@gmail.com**] On Behalf >> Of Rohit Yadav >> Sent: Sunday, February 03, 2013 5:14 PM >> To: >> cloudstack-dev@incubator.**apache.org<cloudstack-dev@incubator.apache.org> >> Subject: Re: [DISCUSS] Packaging in 4.1 >> >> On Mon, Feb 4, 2013 at 4:41 AM, David Nalley <da...@gnsa.us> wrote: >> >>> On Sun, Feb 3, 2013 at 3:58 PM, Rohit Yadav <bhais...@apache.org> wrote: >>> >>>> On Sun, Feb 3, 2013 at 3:07 PM, David Nalley <da...@gnsa.us> wrote: >>>> ... >>>> >>>>> >>>>> So EL6 has pygments 1.1.1 - you require 1.5, so in some ways it's >>>>> worth than clint (clint is in EPEL, but no new version of pygments >>>>> in >>>>> EPEL/CentOS-Extras/CentOS-**Plus) >>>>> >>>> >>>> I want people to use pip to install the cli because it's the easiest >>>> and because rpm/deb packages may have dependency issues like you >>>> mentioned => may not work on all distros, what we can do is when >>>> people install cloudstack-cli rpm or deb, it runs a script that >>>> installs pip (if unavailable) and cloudmonkey. cloudmonkey is pure >>>> python, so the rpm/deb can also ship bundling src tarballs of >>>> cloudmonkey and its dependencies and install from it. Advise best way >>>> of doing this? >>>> >>> >>> I guess we won't be installing the CLI via RPMs at least for EL6. >>> >>> You are assuming that they would have internet access when installing >>> - which is not a valid assumption. >>> >>> Honestly, the above idea makes me blanch. A package that reports as >>> installed, and may or may not have installed - may have installed a >>> compromised package (see rubygems.org compromise recently, kernel.org, >>> and a number of other site compromises.), or might have installed >>> packages I didn't know about is a Bad Idea (tm) The sysadmin doesn't >>> know you are installing some of the dependencies, there is no record >>> of those packages in the package manager, and there might potentially >>> be conflicts with system packages, a security vulnerability in one of >>> those dependencies wouldn't be caught on audit, etc etc. >>> >> >> /facepalm\, it's just a problem of packaging. The package can include cli >> or any other artifact's dependencies, so in case of cli, you bundle both >> pygments and prettytable in cli's rpm/deb. AFAIK all of them are pure >> python so easily installable. The cool people can use pip to install. >> >> >>> And I really don't intend for this to sound like a rant, but the one >>> of the important benefits behind using packages and a package manager >>> is that a sysadmin needs (and often is required to have by government >>> regulations) a single source of truth about the software installed on >>> a machine. >>> >> >> No, it's not a rant, I understand. >> >> Developers love things like Maven central, pypi, CPAN, and rubygems, >>> and for good reason, they are fast, flexible, and make their life >>> easy. To a sysadmin managing machines in production, they are >>> anathema; they make system state difficult or impossible to determine, >>> they make audits painful. >>> >> >> I just assumed the sysadmin who would install CloudStack, cli and whatnot >> won't be stupid, at the same time I want his life to be less miserable. >> >> In addition they make troubleshooting >>> incredibly difficult. Do I have $foo installed - which version? Are >>> there multiple copies of $foo installed on the system? Which one is >>> actually being called/loaded? >>> >> >> Alright, but I'm talking only about the cli, since most users, admins >> included, would want it to run on their machines, the installation should >> be easiest, that's why I said they can use pip, so it works on their >> windows, osx, linux, bsd boxes and that's why it's pure python (written >> that way). >> >> Regards. >> >>> >>> --David >>> >> > -- Engineering Experience, Infrastructure tribe, Spotify
