cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rohit Yadav <rohit.ya...@citrix.com>
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 10:08:50 GMT

On 04-Oct-2012, at 2:45 PM, Noah Slater <nslater@tumbolia.org> wrote:

> 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?

This is just for binary release. For source release, all the code that needs to be shipped
is already in the repository.

> 
> 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.

> 
> 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.

> 
> 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.

> 
> 
>> 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.

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.

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

The build/binary release, won't contain anything that is not compatible with the Apache license.

Thanks for replying,
Rohit

> 
> 
> -- 
> NS


Mime
View raw message