cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rohit Yadav <>
Subject Re: [ASFCS40][DISCUSS] Binary packaging - another round of discussions that I'd like us to come to a conclusion on.
Date Thu, 04 Oct 2012 11:26:46 GMT

On 04-Oct-2012, at 3:59 PM, Noah Slater <> wrote:

> Comments inline.
> On Thu, Oct 4, 2012 at 11:08 AM, Rohit Yadav <> wrote:
>> On 04-Oct-2012, at 2:45 PM, Noah Slater <> wrote:
>>> Can you outline your plan for both the source release and the binary
>>> packages?
>> This is just for binary release. For source release, all the code that
>> needs to be shipped is already in the repository.
> We need to be clear that we are not making binary "releases".

I understand that we're making source releases now, I think I mentioned on IRC that I'm proposing
this for post 4.0.
Sometimes in future we will be doing releases right?

>>> Will the source release contain the source for all the plugins? (My best
>>> guess is yes, and this sounds fine.)
>> Yes, it already does, in plugins/ directory.
> Okay, cool.
>>> If you were providing a binary package, why separate out the plugins?
>> If all plugins artifacts are in separate deb/rpm packages, user has more
>> power to decide which plugin she wants and which she does not.
>> So, if I'm using only xen, I may not want to install kvm, ovm etc.
> I guess my confusion here stems from my time packaging for Debian proper.
> You would never bundle a dependancy in a package. You would just build a
> package for the dependancy, have your main package Depends on it, and let
> APT handle it.

That is correct, that's why we're hoping not to bundle any deps (oss or noss) with the binary
So, for example plugin-kvm can depend of cloud-agent etc.

> Can you clarify for me what your plan is in this regard?

No plan, just proposal. And a proof of concept using a plugin for deb packaging:

> A sample list of
> package names would probably be illustrative. Do you plan to have a main
> deb package for "cloudstack" and then have a package for
> "cloudstack-netapp" which actually bundles manageontap? The way I was
> originally imagining it is that we would provide a single "cloudstack" deb,

This is open for discussion, if we want a monolithic package or few monolithic packages or
bundle everything in separate pkgs.

For the list of debs and exactly what pkgs I'm proposing see below;

> which includes all of the plugins, and then if the user wanted to actually
> use the netapp plugin, they would install manageontap locally.
>>> Sounds like a binary package should contain all of the plugins we ship,
>>> just like a source release.
>> Yes, the non-asf/nonoss plugins won't work unless user install the libs
>> mentioned in 1.
> I'm confused, because you seem to be agreeing, but in your previous
> paragraph you seem to be suggesting that the plugins are bundled up along
> with dependancies in separate packages. Please correct me if I am wrong!

Let me define some terms;
artifact: any jar, war or target created by maven
submodule: a subproject, like api, agent
plugins: they are sub projects and part of the cloudstack source code but they're separate
out of the core logic
deps/libs: used interchangeably, these are dependencies used by various cloudstack artifacts
(jars, wars etc.) to reuse classes, evoke library functions and methods
nonoss libs: such as icontrol, netscaler, vmware jars etc.

Right now, these are the different packages built by the maven jdeb plugin;

Cloudstack pkgs;


Deps, not available on a distr.'s repository bundled here (for example gson.jar is not available
on ubuntu etc.):

Plugins, in plugins/ directory;

>>> This confuses me in the context of the above paragraph. In the above
>>> paragraph, I understand you to be talking about separating out the
>> plugins
>>> for for DEBs and RPMs. But here you seem to be talking about a setup
>> where
>>> is fetching 3rd party non-OS software, so that it can
>>> prepare a binary build that contains all the plugins and is properly
>> linked.
>> You understand correct, my question is, will ASF allow such a process.
>> It's just like installing gcc and libs and building code and removing
>> gcc/libs; not that we use gcc or its libs.
> We need to ask legal-discuss and infra. I have done that now.


On second though, what I'm proposing may become very complex to handle.
So, I'm dropping the idea. (to be picked up by someone else :)


> Thanks,
> -- 
> NS

View raw message