[Debichem-devel] [Debichem-commits] [debichem] r5051 - unstable/abinit/debian

Andreas Tille andreas at an3as.eu
Fri Jan 24 07:34:26 UTC 2014


Hi Michael,

thanks for stepping in to abinit packaging.

On Fri, Jan 24, 2014 at 01:26:07AM +0100, Michael Banck wrote:
> 
> First of all, I built abinit now and noticed that it runs the testsuite
> with 6 processes in parallel.  I think this is not very nice to the
> buildds, we should limit ourselves to two processes max (or maybe 2 MPI
> processes with two threads each, in order to get some better testing).

How can you restrict the number of processes (I only know '--parallel' or
droping this option)?
 
> Further, I had a look at the contents of those packages, and I'd like to
> object to the name -examples:
> 
> 1. Those are not just example input files but also reference outputs.

I agree.  My attempt was to kick the files fro the abinit-doc package
where they were before to not bloat the normal user with several unused
MBytes.

> 2. Those are actually not examples how to properly run Abinit, but
> testsuite inputs, i.e. they are not targetted at end users.  See the
> tests/README:
> 
> |These tests are designed primarily to exercise parts of the code
> |quickly, NOT necessarily to give physically sensible results.
> |For greater speed, some tests are not run to full convergence.
> |Also the quality parameters (especially ecut) are minimal, i.e.
> |the calculations are underconverged.

Just suggest a better name.  I considered "-examples" as a frequently
used name while I have rarely seen packages named "*-tests" and finally
tests can also serve as examples.  I'm fine with any better suggestion.

> 3. They ship pseudo-potentials as well, not just input and output files.
> 
> 4. A lot of them are not applicable right now, e.g. because we don't use
> the bigDFT or libXC modules.
> 
> So far, my strategy with similar issues was as follows:
> 
> 1. Ship the pseudo-potentials under /usr/share/<package>, at least as
> long as it is not clear that those are underconverged or otherwise buggy
> (and just for testing) as well. This also means to modify the package to
> check for the pseudo-potentials in that directory (at least as a backup
> solution).
> 
> 2. Curate a small set of useful input files as examples for
> /usr/share/doc/<package/examples.
> 
> 3. Ship all those (and the documentation) in a package <package>-data,
> which the main package depends or recommends upon.
> 
> Now, I see the benefit in sipping the testsuite so that
> post-installation validation can happen, but this does not appear to be
> the case right now and arguably, it should not be in an -examples
> package and/or in an examples/ directory.
> 
> Finally, are you sure the whole (also the developer oriented)
> documentation is useful?

Well, I'm not sure at all.  As you know abinit was totally orphaned and
unmaintained.  My intention was to provide something more reasonable
than we had before.  I admit that the points you made are all valid but
neither my knowledge in this topic nor the time I could spend into this
are sufficient to implement the things you suggested.
 
> At least the manpage abinit.1 should get moved to /usr/share/man/man1.

???
It is there.
 
> I hope you are not very angry at me if I ask to reject the current
> NEW upload, so that we can find consesus on the package name and
> content, before the name has been leaked into unstable.

Perfectly to the contrary:  I'm very happy that my initial work might
lead to more than I could personally do.  I had some bad feeling to push
some additional work on the DebiChem team when injecting the package
here.  If you think you want to enhance the package from "definitely
better and at least up to date than before" to "meeting high standards
with a review of single files enabling autopkgtest" this would be a
really great outcome of my initial work to bring an orphaned package
under team maintenance.

> Sorry it took me a while to answer, but I didn't manage to check out the
> actual contents of the packages until I built them now.

No problem.  Thanks for your review in any case

      Andreas.

-- 
http://fam-tille.de



More information about the Debichem-devel mailing list