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

[Karol M. Langner]

On Fri, Jul 22, 2011 at 04:28:28PM +0200, Michael Banck wrote:
> Hi,
> 
> On Mon, Jul 18, 2011 at 08:59:12AM +0200, Karol M. Langner wrote:
> > Here is the cclib source package:
> > http://mentors.debian.net/debian/pool/main/c/cclib/
> > which creates cclib and python-cclib and doesn't contain any of
> > the offending files. Note that the package cclib contains just two scripts,
> > but I guess that's OK because in the future it should get more content.
> > 
> > Here is the cclib-data source package:
> > http://mentors.debian.net/debian/pool/main/c/cclib-data/
> > which is meant for non-free and has the remaining data and test scripts.
> > 
> > Does this look OK?
> 
> I took a look now, and found a few issues:
> 
> 1. Packages in main (e.g. cclib) must not Depend on or Recommend
> packages in non-main, but you can put a Suggests: cclib-data to hint
> users and graphical package managers.  This still means cclib-data will
> not be installed along python-cclib for a regular apt-get or aptitude
> install run.

Added.

> Possibly cclib could print out a warning that cclib-data is not present
> and additionally (if run on a Debian system), point users to the
> cclib-data package in non-free.

I can't think of a good place to do that. And since cclib-data is
basically tests, which are useful but not really interesting to users,
I don't think that's really needed.

> 2. The section for cclib-data should be non-free/science rather than
> just science.  Note how the package ended up under debian/pool/main on
> mentors.debian.net, not debian/pool/non-free.

OK

> 3. The Depends: python-cclib (= 1.0.1-1) in cclib-data should probably
> be relaxed a bit.  I guess it works, but is there any interface-like
> dependency between the both?   Just depending on python-cclib (or
> possibly python-cclib (>= 1.0.1) or something might be enough and could
> avoid upgrade issues later on (e.g. if a user removes non-free from
> their sources.list again for some reason, and apt/aptitude refuse to
> upgrade cclib because a stale cclib-data package still depends on the
> exact earlier version).

Good point. The unittests do use the cclib API, and we don't really
strive for backwards compat., but this should be fine 99% of the time.

> 4. You could add "(python module)" and "(data files)" or something to
> the short descriptions of python-cclib and cclib-data to make it clearer
> what the difference is to the main cclib package.

Done.

> 5. What does the "noninteractive use" in "This package contains helper
> scripts for noninteractive use." mean?  Does python-cclib have helper
> scripts for interactive use?  Or just that those scripts are
> noninteractive, and there are no others?  In that case, maye "for end
> users" or something might be clearer.

Another good point, thanks! These are the only scripts, there are none
in python-cclib.

> 6. The fix_setup.patch patch from cclib ended up in cclib-data as well
> as debian/patches/debian-changes-1.0.1-1, was this intentional?  If so,
> I suggest renaming it to fix_setup.patch as well, as the
> debian-changes-* patches are auto-generated by dpkg-dev.

Thanks for pointing that out.

> 7. I get a build failure for cclib, if I build it in a (hopefully)
> current unstable environment:
> 
> /bin/sh: python2.7: not found
> 
> I get this:
> 
> nighthawk~/build$ pyversions -vs
> 2.6 2.7
> 
> I am not a python build expert, but either you have to specify both
> currently supported python versions (python2.6 and python2.7) as
> Build-Depends, or you just build for the default version (2.6 currently)
> with pyversions -vd.

I went with just the default version, as it seems that is the preference for
most debichem packages I've looked at today.

> That's all I saw at a first glance, will try to take another look later.

OK, thanks again. I've now uploaded the newly built packages to mentors.debian.net,
but the changes are not commited to the svn repo yet as I explained in another email.
Hopefully I'll get around to that tomorrow.

Let me know if there are any other issues I can address.

Cheers,
Karol

-- 
written by Karol M. Langner
Sun Jul 24 22:50:50 CEST 2011