incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <nsla...@tumbolia.org>
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 09:15:17 GMT
Comments inline.

On Wed, Oct 3, 2012 at 7:40 AM, Rohit Yadav <rohit.yadav@citrix.com> wrote:

> 2. While building these required jars are needed to be build against them,
> linking means only class definitions are verified and the plugin is
> compiled. No class is copied from these nonoss libs to these plugins. For
> running these plugins, the above mentioned requirement/deps/jars should be
> in their class path.
>

Sounds good.


> My proposal is to have individual packages (rpms, debs) for these plugins
> which won't have any of these non-ASF libs/jars. A user whose has rightful
> ownership of these non-ASF jars will be just required to install them, and
> install any of these plugins and configure them correctly in the conf files
> mentioned in 3.
>

Confused by this bit.

Can you outline your plan for both the source release and the binary
packages?

Will the source release contain the source for all the plugins? (My best
guess is yes, and this sounds fine.)

If you were providing a binary package, why separate out the plugins?

Sounds like a binary package should contain all of the plugins we ship,
just like a source release.


> On build.apache.org, to build cloudstack, we can wget a patch which would
> contain the non-ASF jars mentioned in 1. from non-ASF hosting, build these
> CloudStack debs and rpms, and delete this patch.
>

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
build.apache.org is fetching 3rd party non-OS software, so that it can
prepare a binary build that contains all the plugins and is properly linked.

Let me re-emphasize, the builds won't contain
>

Won't contain...?


-- 
NS

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message