Nice to see native packages for Cloudstack : https://github.com/noaresare/incubator-cloudstack/tree/master/packaging
CentOS 6.3 and Debian. Did there is plan to add Fedora, openSUSE, SLES or will it be done by these distributions packagers ? 2013/2/4 Wido den Hollander <w...@widodh.nl>: > Hey, > > I just pushed everything to the Github repo[0]: > > dpkg-genchanges -b >../cloudstack_4.1.0-0.0.snapshot+2_amd64.changes > dpkg-genchanges: binary-only upload - not including any source code > dpkg-source --after-build cloudstack > dpkg-buildpackage: binary only upload (no source included) > > wido@wido-desktop:~/repos/cloudstack$ ls -l ../*.deb > -rw-r--r-- 1 wido wido 176298 Feb 4 21:14 > ../cloudstack-agent_4.1.0-0.0.snapshot+2_all.deb > -rw-r--r-- 1 wido wido 2382 Feb 4 21:14 > ../cloudstack-awsapi_4.1.0-0.0.snapshot+2_all.deb > -rw-r--r-- 1 wido wido 2302 Feb 4 21:14 > ../cloudstack-cli_4.1.0-0.0.snapshot+2_all.deb > -rw-r--r-- 1 wido wido 24629096 Feb 4 21:14 > ../cloudstack-common_4.1.0-0.0.snapshot+2_all.deb > -rw-r--r-- 1 wido wido 2280 Feb 4 21:14 > ../cloudstack-docs_4.1.0-0.0.snapshot+2_all.deb > -rw-r--r-- 1 wido wido 85635152 Feb 4 21:14 > ../cloudstack-management_4.1.0-0.0.snapshot+2_all.deb > -rw-r--r-- 1 wido wido 91854 Feb 4 21:14 > ../cloudstack-usage_4.1.0-0.0.snapshot+2_all.deb > wido@wido-desktop:~/repos/cloudstack$ > > I can't guarantee that they work for 100%, but it should be a start! > > Wido > > [0]: https://github.com/noaresare/incubator-cloudstack/commits/packaging > > > On 02/04/2013 06:04 PM, Wido den Hollander wrote: >> >> >> >> On 02/04/2013 06:03 PM, Hugo Trippaers wrote: >>> >>> Hey guys, >>> >>> What do we do with the database scripts? They are needed by >>> cloud(stack)-setup-management. I'm thinking about adding them to the >>> management server for now together with the scripts. There are some >>> python modules (cloudutils and cloud_utils) which are needed by both >>> setup tools in management and agent to I thought to put those in common. >>> >> >> Ran into the same! Had the idea to put them indeed in the management >> server package. >> >> The python libs should indeed go into common. >> >> Wido >> >>> Cheers, >>> >>> Hugo >>> >>>> -----Original Message----- >>>> From: Wido den Hollander [mailto:w...@widodh.nl] >>>> Sent: Monday, February 04, 2013 2:48 PM >>>> To: cloudstack-dev@incubator.apache.org >>>> Subject: Re: [DISCUSS] Packaging in 4.1 >>>> >>>> On 02/04/2013 02:39 PM, Noa Resare wrote: >>>>> >>>>> I'm on the last leg of my trip home from FOSDEM right now, I hope to >>>>> be able to put in some work on deb packages in the next few days. >>>>> >>>> >>>> I still have some pending changes on my laptop which I forgot to push >>>> to the >>>> Github repo[0]. >>>> >>>> I'll push them in a couple of hours, they contain a lot of what we >>>> discussed >>>> regarding the DEB packaging. >>>> >>>> Wido >>>> >>>> [0]: https://github.com/noaresare/incubator-cloudstack >>>> >>>>> /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.apach >>>>>>> >>>>>>> e.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 >>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>> >
