[Debichem-devel] cclib_1.0.1-1_i386.changes REJECTED

Michael Banck mbanck at debian.org
Sun Jul 17 14:53:49 UTC 2011


Hi,

On Sun, Jul 17, 2011 at 04:40:59PM +0200, Karol M. Langner wrote:
> I'd like to get back to the issue of cclib...

Yeah, sorry for letting it drop...
 
> On Fri, Apr 22, 2011 at 11:55:50AM +0200, Michael Banck wrote:
> > On Thu, Apr 21, 2011 at 09:13:56PM +0200, Daniel Leidert wrote:
> > > Am Donnerstag, den 21.04.2011, 10:11 +0200 schrieb Karol M. Langner:
> > > > What else can be done? In the worst
> > > > case scenario, should I remove all tests from the package?
> > > 
> > > Indeed. 
> > 
> > Well, the question is whether just the ADF files are offending, or
> > whether ftp-master stopped looking there and after we've removed those,
> > complains about the next set.
> 
> Almost all of the test files are offending.
 
Right.

> > > One alternative might be: Put these files into a separate source
> > > and binary package into non-free. Then let cclib build-depend on this
> > > package. Unfortunately a package in main must not (build-)depend on any
> > > package outside main (or unpackaged software). So you would have to put
> > > cclib in contrib. 
> > 
> > I don't think that would be very helpful. AIUI, those files are not
> > strictly needed for building the package, just for validation?
> > 
> > In that case, suggesting the data package in non-free would be fine.
> >
> > > IMO changing the EULA or removing these files is the best thing we can
> > > do.
> > 
> > As long as this is just about ADF, just removing those would be a good
> > compromise I think.
> 
> That is right -- these files are not needed for building, just validation.
> 
> If I want to make a data package and put it in non-free, does that mean
> I need to have two different source packages?

Yes, that would be best.  You don't necessarily have to do it upstream,
we could just strip the data files out off the "real" package and create
a new source package with those.  But for Debian's purposes, two source
packages would be required.


Michael



More information about the Debichem-devel mailing list