This is the workflow I'm suggesting: (non-ASF = not compatible with Apache
license, may be open source or proprietary)
1. There are 5 plugins and vmware-base which are the only part of the source
code which requires external/nonoss libs for building and runtime:
a. netapp, requires: manageontap
b. vmware, requires: vmware-{vim, vim25, apputils, jaxrpc}
c. srx, requires: icontrol
d. netscaler, requires: netscalar{,sdk}
e. f5, requires: icontrol
f. vmware-base, requires: vmware-{vim, vim25, apputils}
Note, these plugins and vmware-base are part of CloudStack and are under Apache
License.
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.
3. These plugins must be activated in components.xml and class paths added in
class path.conf
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.
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.
Let me re-emphasize, the builds won't contain
My question is, it possible to do all of the above?
Regards.
On 02-Oct-2012, at 2:09 PM, Noah Slater <nsla...@tumbolia.org> wrote:
> (For clarity, in this email non-OS means "not compatible with the Apache
> license.")
>
> Can you clarify what "link" means in this context? You need to be careful
> with licenses such as the GPL, which expressly prohibit linking (in quite a
> vague sense) unless the your software is also GPL. (Which is what the LGPL
> was for.)
>
> But beyond that, as long as the source tarball that we release contains no
> binaries (of any sort) and nothing that is incompatible with our license,
> then we should be fine. (I am not sure about the build question. In
> general, I don't think it is problematic to have non-OS software on our
> systems. JIRA for example! But we would have to check the specifics with
> Infra.)
>
> Though that does make me wonder about how much non-OS stuff is required on
> the installation machine. I am presuming the core of will work, and it is
> just that some plugins will not work unless you have the required non-OS
> dependancies locally?
>
> In fact, to make doubly sure, is this the situation you're describing:
>
> 1. Build the source release of CloudStack with plugin sources that can
> only be compiled with non-OS software present (note that the compilation
> does not happen during the source release, we only ship the source of them.)
> 2. Prepare binary packages from the source release that compile the the
> non-OS plugins with the non-OS software present (and distribute these from
> non-ASF locations)
> 3. Users download the binary packages and use the non-OS plugins if they
> have that non-OS software locally
>
> For 1) what happens if you're installing form the source release, and you
> don't have the non-OS software present?
>
> For 2) do you need the non-OS software present to compile the plugins when
> preparing the binary package?
>
> For 3) what happens if you're installing from the binary package, and
> don't have the non-OS software present?
>
>
> On Tue, Oct 2, 2012 at 9:14 AM, Rohit Yadav <rohit.ya...@citrix.com> wrote:
>
>> Moving binary packaging discussion with Noah from another thread here;
>>
>>> Just a clarification here. It is fine to use, or depend on proprietary
>>> software that exists on the system. During the build, or after install.
>>> "For example, using a GPL'ed tool during the build is OK." [1] The
>>> stipulation is that we cannot ship anything WITH the build that is
>>> incompatible with our license.
>>>
>>> [1] http://www.apache.org/legal/resolved.html
>>
>> Thanks Noah, so if we build CloudStack against nonoss deps/libs (on
>> non-ASF infra, not likely but if possible on ASF infra) and publish the
>> binary (which won't have any non ASF compliant libs/deps/artifacts) on ASF
>> infra that will work?
>> Only the plugins (which are all ASF compliant) are linked against these
>> nonoss libs.
>> If we do this, we won't have to do separate builds, nonoss/oss, less
>> trouble for QA and a user will be just required to install nonoss libs/deps
>> to have the plugins work.
>>
>> Let's do this?
>>
>> Regards.
>>
>> ________________________________________
>> From: Noah Slater [nsla...@tumbolia.org]
>> Sent: Sunday, September 30, 2012 11:10 PM
>> To: cloudstack-dev@incubator.apache.org
>> Subject: Re: [ASFCS40][DISCUSS] Binary packaging - another round of
>> discussions that I'd like us to come to a conclusion on.
>>
>> This all sounds good to me.
>>
>> What would be the difference between the src.tar.gz and the jar one?
>>
>> On Wed, Sep 12, 2012 at 8:55 PM, Chip Childers <chip.child...@sungard.com
>>> wrote:
>>
>>> All,
>>>
>>> This is another issue that we need to come to a consensus on (and I
>>> think we can do lazy consensus if required here) prior to 4.0 being
>>> released.
>>>
>>> We've variously been discussing how to best provide binary artifacts
>>> from the 4.0 release. Knowing that we are purely discussing
>>> convenience builds for users, and that ASF releases are source only,
>>> I'd like to propose the following approach.
>>>
>>> I propose that the project only publishes source tarballs to the ASF
>>> mirrors, and that we rely on the community at large to publish binary
>>> build artifacts.
>>>
>>> Wido has volunteered to host deb and rpm repos containing packages
>>> built from the source, and I know that (over time) we will see the
>>> actual distributions put cloudstack packages together. I would
>>> imagine (and am not speaking for Wido), that we could work with Wido
>>> to ensure that his hosted repos have the latest release in them. We
>>> would then be in a position where it's OK if a specific distro
>>> packaging community is a version or two behind the ASF releases. That
>>> scenario would allow us to point users that want the very latest
>>> release to the custom repo, but folks that want official distro
>>> packages can simply use the version being provided by their OS's
>>> packaging system.
>>>
>>> For the convenience of the community, I'd further propose that we
>>> provide a set of links to these community repos on our download page
>>> (including appropriate verbiage about the URLs not representing
>>> official ASF release artifacts). This would also include instructions
>>> for how to setup a RHEL/CentOS/Ubuntu system to pull from Wido's
>>> hosted repos.
>>>
>>> As for QA teams involved in the testing of ASF releases, I believe
>>> that we should continue to use jenkins.c.o (with Citrix's agreement
>>> and continued support) as the source for downloading packages for
>>> testing. This is because it can do it for us on a nightly schedule.
>>>
>>> There is one optional part of this proposal: we include a tarball of
>>> cloudstack jar files on the ASF mirrors. Although, I'm just not sure
>>> what value that provides to the community.
>>>
>>> Thoughts?
>>>
>>> -chip
>>>
>>
>>
>>
>> --
>> NS
>>
>
>
>
> --
> NS
