Thanks for the information! Don't let my confusion put you off. I'm just making sure we have our ducks in a row. I don't have the time to respond to this in full today, but I'll come back to this thread tomorrow. However, I did just want to report back that the first response on legal-discuss seems to indicate that we can build binary packages that link against legally incompatible 3rd party software. With the stipulation that this is NOT the default for users who are building from the source release.
And just to clarify one other point, we will NEVER do a binary release. A "release" (and thanks for clarifying terminology for me!) is something which is VOTEd on by the community. We will never vote on binary packages. We are free to provide them to accompany source releases, as a matter of convenience. And we can build and host these on ASF infra. On Thu, Oct 4, 2012 at 12:26 PM, Rohit Yadav <rohit.ya...@citrix.com> wrote: > > On 04-Oct-2012, at 3:59 PM, Noah Slater <nsla...@tumbolia.org> wrote: > > > 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". > > 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 releases. > 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: > https://github.com/bhaisaab/incubator-cloudstack/tree/debs-maven > > > 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; > > ./agent/target/cloud-agent_4.0.0+SNAPSHOT.deb > ./api/target/cloud-api_4.0.0+SNAPSHOT.deb > > ./client/target/cloud-client-ui-4.1.0-SNAPSHOT/target/cloud-client-ui_4.0.0+SNAPSHOT.deb > > ./client/target/cloud-client-ui-4.1.0-SNAPSHOT/WEB-INF/classes/scripts/target/cloud-scripts_4.0.0+SNAPSHOT.deb > ./client/target/generated-webapp/target/cloud-client-ui_4.0.0+SNAPSHOT.deb > > ./client/target/generated-webapp/WEB-INF/classes/scripts/target/cloud-scripts_4.0.0+SNAPSHOT.deb > ./core/target/cloud-core_4.0.0+SNAPSHOT.deb > ./scripts/target/cloud-scripts_4.0.0+SNAPSHOT.deb > ./server/target/cloud-server_4.0.0+SNAPSHOT.deb > ./setup/target/cloud-client-ui_4.0.0+SNAPSHOT.deb > ./target/scripts/target/cloud-scripts_4.0.0+SNAPSHOT.deb > ./target/ui/target/cloud-client-ui_4.0.0+SNAPSHOT.deb > ./ui/target/cloud-client-ui_4.0.0+SNAPSHOT.deb > > Deps, not available on a distr.'s repository bundled here (for example > gson.jar is not available on ubuntu etc.): > ./deps/target/cloud-deps_4.0.0+SNAPSHOT.deb > > Plugins, in plugins/ directory; > > ./deployment-planners/user-concentrated-pod/target/cloud-plugin-planner-user-concentrated-pod_4.0.0+SNAPSHOT.deb > > ./deployment-planners/user-dispersing/target/cloud-plugin-planner-user-dispersing_4.0.0+SNAPSHOT.deb > ./file-systems/netapp/target/cloud-plugin-netapp_4.0.0+SNAPSHOT.deb > > ./host-allocators/random/target/cloud-plugin-host-allocator-random_4.0.0+SNAPSHOT.deb > ./hypervisors/ovm/target/cloud-plugin-hypervisor-ovm_4.0.0+SNAPSHOT.deb > > ./hypervisors/vmware/target/cloud-plugin-hypervisor-vmware_4.0.0+SNAPSHOT.deb > ./hypervisors/xen/target/cloud-plugin-hypervisor-xen_4.0.0+SNAPSHOT.deb > > ./network-elements/elastic-loadbalancer/target/cloud-plugin-network-elb_4.0.0+SNAPSHOT.deb > ./network-elements/f5/target/cloud-plugin-network-f5_4.0.0+SNAPSHOT.deb > > ./network-elements/juniper-srx/target/cloud-plugin-network-srx_4.0.0+SNAPSHOT.deb > > ./network-elements/netscaler/target/cloud-plugin-network-netscaler_4.0.0+SNAPSHOT.deb > > ./network-elements/nicira-nvp/target/cloud-plugin-network-nvp_4.0.0+SNAPSHOT.deb > ./network-elements/ovs/target/cloud-plugin-network-ovs_4.0.0+SNAPSHOT.deb > > ./storage-allocators/random/target/cloud-plugin-storage-allocator-random_4.0.0+SNAPSHOT.deb > > ./user-authenticators/ldap/target/cloud-plugin-user-authenticator-ldap_4.0.0+SNAPSHOT.deb > > ./user-authenticators/md5/target/cloud-plugin-user-authenticator-md5_4.0.0+SNAPSHOT.deb > > ./user-authenticators/plain-text/target/cloud-plugin-user-authenticator-plaintext_4.0.0+SNAPSHOT.deb > > > > > > >>> 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. > > 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 :) > > Regards. > > > > > > Thanks, > > > > -- > > NS > > -- NS
