On 02/05/2013 06:33 PM, Noa Resare wrote:
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

Yes, I stumbled upon the same while merging master into packaging.

It doesn't hurt anybody to keep it in the current shape, the end result will be the same.

Wido


/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





Reply via email to