incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Nalley <>
Subject Re: [DISCUSS] Packaging in 4.1
Date Sun, 03 Feb 2013 09:19:25 GMT
On Sun, Feb 3, 2013 at 4:04 AM, Rohit Yadav <> wrote:
> On Sun, Feb 3, 2013 at 2:19 PM, David Nalley <> wrote:
>>> Alright, we will also have to implement upgrade paths and
>>> s/cloud-/cloudstack-/g in a lot of scripts.
>>>> I this the best we to demonstrate is by showing code, instead of a lengthy
email ;-) All packages will have a directory in /usr/share/cloudstack-%{name}
>>> Why not /usr/share/cloudstack/%{name}? cloudstack-cli would have to be
>>> installed like any other python app, in /usr/*path to python 2.6 or
>>> 2.7 dir*/site-packages/cloudmonkey, or there will be some other format
>>> of installation?
>> WRT to marvin and cloudmonkey - they will be in site-packages - well
>> that is assuming that we package them. We want to, but at least in
>> RHEL/CentOS, there are dependencies for cloudmonkey (clint) that don't
> I got rid of clint, at present cloudmonkey uses pygments for lexical
> parsing and color printing (for future this can also be used to do
> html output stuff), prettytables for tabular output, these are the
> only two external dependencies. cloudmonkey does not depend on marvin
> as well, against a running mgmt server a precache can be created for
> building/packaging cloudmonkey or you do: cloudmonkey sync that
> discovers new apis and generates a cache for the user. Since pygments
> is pretty widely used it may not be a problem for most distros also I
> can write cloudmonkey's own tabular printing so it won't depend on
> prettytable.

Doh! - that's what I get for not looking in source and depending on
memory. That's good to know.


View raw message