[Debichem-devel] p4VASP packaging

[Michael Banck]

Hi Graham,

sorry for the radio silence, I was rather short on time for DebiChem
over the past weeks and only had another look at p4vasp now.

On Thu, Mar 06, 2014 at 10:45:56AM +0200, Graham Inggs wrote:
> Since my last email, upstream released the minor update 0.3.29.
> 
> I have been experimenting with various ways of splitting the packaging,
> producing separate shared objects for the libraries, etc.  I see four
> different ways of doing it.
> 
> 1. Produce a single package without the large API documention.  This is the
> way upstream's build system works.  My current packaging in git builds a
> single binary package and includes the API documentation so it will be
> quick to get
> 
> 2. Split the package into the gui application, a libp4vasp shared object, a
> python-p4vasp module and separate API documentation.

In general, I would say splitting off the library in a third package
would not be necessary.  The .so and the python files could be together
in a python-p4vasp package.  This only holds if the anticipated usage is
mostly via python, if the library is going to be used as well, then
yeah, it could be also split off.  But see my remarks below.
 
> 3. Split the package into the gui application, a libp4vasp shared object,
> and a python-p4vasp module and separate API documentation.  Package ODPdom
> separately from the SourceForge tarball (patched to with changes from
> p4vasp) and produce a libodpdom shared object and a python-odpdom module.
> 
> 4. As above, but produce the odpdom packages from the p4vasp source
> instead.  The odpdom package version numbers will then have the same
> version as the p4vasp packages, but since upstream do not intend
> maintaining odpdom separately (see below) I don't think this will be a
> problem.
> 
> Upstream had the following to say:
> 
> I was hoping that somebody will use it (ed: the p4vasp library), but I
> > never ever obtained a single question about how to use the library - so I
> > am almost sure it is not used and does not need to be maintained as a
> > library.
> > The same holds for odpdom - I have no interest in maintaining the package
> > as a separate library - not even I use it for anything else than p4vasp...
> >
> > On the other hand, the greatest challenge was (and still is) to make
> > p4vasp easily installable. In order to achieve that, I have intentionally
> > "demodularized" the p4vasp.
> > Again - if I'll find at least one user of odpdom, libp4vasp or the p4vasp
> > python module, I am willing to reconsider the modularity, otherwise in my
> > eyes p4vasp is simply a monolithic desktop application
> > I as well think you should not waste your time by modularizing p4vasp (I
> > would have a bad consciousness if I would let you do that). However - if
> > you still think that p4vasp should be split, we can discuss that.
> >
> 
> At this stage, I am inclined to go with option 1, but if we think having
> the separate libraries in Debian might prove useful, I am prepared to go
> with option 4.  I would like to hear your opinion.

I concur about shipping it as one application for now, this also lets us
ignore what to do about the forked odpdom for now.

You talk about API documentation above, but I don't see any in the .deb
I built, did that get stripped again or is this some in-app feature with
a non-standard location?

If this is a self-contained application package, it might be useful not
to ship the API documentation anyway, until there are users of it and/or
the library/API is split off into its own package.  But that's your
call.

Same goes for the header files.  I see you remove the .a static
libraries, but then the header files serve no purpose either, because
you can include them, but not link anything in.

I am not sure about the location of _cp4vasp.so.  This is a python
extension module in C, not a C library really, I guess.  Currently you
put it in /usr/lib, but I would say it should be moved to
/usr/lib/python$(PYVERSION)/dist-packages or so, see e.g. the top of
https://packages.debian.org/sid/amd64/python-bzrlib/filelist (the ones
in pyshared are symbolic links to ../../python$(PYVERSION)/dist-packages
AFAICT).  See also the python-avogadro package as an example.

Further notes:

1. Too bad there are no example files shipped, but with those non-free
codes, I guess it might be difficult to ship them anyway.  Maybe input
files would be fine, you could maybe talk to upstream about this.

2. As I don't have access to VASP, I couldn't really test it out.  What
I noted is that the sqlite database setup is not very straight-forward -
it tells the user to edit a config file, but from a first glance, that
file seems fine as a default (unless you want to use mysql).  However,
when I start p4v from the command-line and try to use the database I get
a traceback:

|ConfigParser.MissingSectionHeaderError: File contains no section
|headers.
|file: /home/mba/.p4vasp/database.cfg, line: 2
|'  [DEFAULT]\n'

This is likely an upstream problem, but I thought I'd mention it here.

That's all for now I guess.

Cheers,

Michael