[Debichem-devel] p4VASP packaging

[Graham Inggs]

Hi Michael / Debichem Team

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.

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.

Regards
Graham
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/debichem-devel/attachments/20140306/dfbee8f1/attachment.html>