On Fri, Jul 20, 2012 at 3:35 PM, Robert Schweikert <rjsch...@suse.com> wrote:
> On 07/20/2012 03:13 PM, David Nalley wrote:
>>
>> In one of the OSCON discussions, I noted the recent polite discussion
>> re binary jars in source releases on general@incubator. While this is
>> apparently tolerated (if you don't mind wearing Nomex), it's
>> considered a Bad Thing (TM) generally speaking. Folks suggested that
>> we look at how subversion handles this. In short, Subversion has a
>> script that downloads all of their dependencies in binary form - and
>> they also provide a download for the deps as a tarball.
>>
>> This made me think that perhaps we should add a .gitignore entry for
>> .jars in deps/ (and tools/), and write a script that downloads the
>> specific versions of the dependencies that we need and depending on
>> argument, either places them in the deps/ directory or creates a
>> tarball. (hopefully verifying {md5|sha1}sum for each binary along the
>> way)
>>
>
>
> Getting rid of the .jars in the source tree is great and I am a very strong
> proponent of this, as stated in another thread a while back.
>
> I question the need to download anything automatically, and thus the
> proposed script.
>
> From a developer point of view I would say one would want to know what is
> getting used. Automatic downloading hides things and thus opens the door for
> "oh I didn't know" or "oops I didn't realize...". I think dependency in
> tools are things the developer is responsible for and a developer better
> know what is needed on the build system.
>
> Packagers should create a cloudstack-devel package that depends on all the
> things needed to set up a development system and all these dependencies
> should be spelled out explicitly in the documentation such that a developer
> that uses a distro that does not package cloud stack can easily get the
> dependencies and install them.
>
> The automatic download has the additional disadvantage that there is
> potential over lap between a package manager and the script. For example if
> I know I need x.jar to develop cloudstack and x.jar is available from my
> distros repo then I will install it and get hacking. Now if we have a script
> that automagically does me favors I get another copy of X.jar on my system.
> This of course may be different then the one from the distribution and there
> might be interference at some point in some unexpected way.
>
> In summary:
>
> - Lets get rid of the jars
> - spell out everything needed in the doc
> - make sure that all these dependencies can be built by distros
To be clear - I wasn't advocating for something to happen without
intervention, but rather for someone to have the choice to use that
script to pull all of the dependencies down. This is particularly
important for platforms without decent package management systems, but
I'd personally see this as a developer tool; with
.rpms/.debs/production deployments I wouldd expect dependency
resolution to handle this sanely instead of deploying a binary blob of
jars.
--David
