Comments inline. On Thu, Oct 4, 2012 at 11:08 AM, Rohit Yadav <rohit.ya...@citrix.com> wrote:
> > On 04-Oct-2012, at 2:45 PM, Noah Slater <nsla...@tumbolia.org> 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". > > 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. Can you clarify for me what your plan is in this regard? 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, 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! > > 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. We need to ask legal-discuss and infra. I have done that now. Thanks, -- NS
