incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Shahaf <...@daniel.shahaf.name>
Subject Re: Binary dependencies in source releases (Was: [VOTE] Release ManifoldCF 0.5-incubating, RC0)
Date Thu, 29 Mar 2012 13:41:12 GMT
Jukka Zitting wrote on Thu, Mar 29, 2012 at 14:41:02 +0200:
> Hi,
> 
> On Wed, Mar 28, 2012 at 5:19 PM, Leo Simons <mail@leosimons.com> wrote:
> > Shipping a set of CDDL jars out of some java.net projects that oracle
> > has all but abandoned is far beyond my imagined threshold of
> > reasonable on the scale. Do you actually see that differently?
> 
> Agreed. These are exactly the kinds of questions that legal-discuss@
> has been working on. I.e. which kinds of dependencies are acceptable,
> and how they should be referenced/included/documented/etc.?
> 
> It seems like Roy is much more categorical about this. Assuming I
> understand his point correctly, *no* binary dependencies are
> acceptable within a source tarball.
> 
> What I don't quite (yet) understand is how a reference like
> "junit:junit:4.10" to a download service maintained by a third party
> is more acceptable than directly including the referenced bits. The
> only difference I see is whether we have the right to redistribute
> those bits ourselves, but that question is already covered by legal.
> 

junit is only needed for unit tests and not for the software itself; is
this relevant to the example?

> Another thing I don't understand is how a configure script compiled by
> autoconf from sources in configure.in and the autoconf distribution is
> any less a binary artifact than a dependency jar. Reviewing a ~1MB
> configure script is about as easy as reviewing the decompiled contents
> of a binary jar.
> 

Have you tried it?  At Subversion we use the same autoconf throughout
a release branch, so comparing two successive 1.6.x tarballs (expanded
tarballs, which include compiled swig and and configure code) wasn't
impossible.  And for 1.6.0, had I wanted to, I could have run the
rolling script myself to generate my own versions of the tarballs
locally, and compare those.

(Hmm, did you mean 'configure' just as an example? :-)) 

> That's a lot I don't understand. If this is as clear an issue as is
> being claimed, I'm sure someone will jump in to educate me.
> 
> > What is the alternative you're thinking of? Is it merely about the
> > process by which we clean things up, or is there some other kind of
> > more fundamental alternative?
> 
> The obvious alternative would be to bless the de facto practice from
> the past 10+ years as being acceptable also de jure.
> 
> BR,
> 
> Jukka Zitting
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message