Bugzilla Bug 124791

I've got pdb2pqr running just fine with a default install (as per the
instructions) using the package from sourceforge. pdb2pqr is a useful package
used in manipulating protein structure files for electrostatics calculations.
(I'll file another feature request for apbs too...)
Thanks,
je_fro

If you guys want me to generate the ebuild, just tell me....I'll attach it when
I'm done.

Sure, attach an ebuild.

Created an attachment (id=81372) [edit]
ebuild for pdb2pqr

Here's an ebuild for pdb2pqr...I'm sure there's a better way to achieve the
install, but I couldn't figure out how to split it up (/usr/share, /usr/bin,
etc...) so I put it all in /usr/lib/python-2.4/site-packages (like pymol) even
though it's not a "distutils package".
Or I may not have a complete understanding of distutils.
Anyway, my other option was to put it in /opt, but this way seems better...
Later,
je_fro

Hi Jeff,

Thanks for your ebuild. It looks nice and here are several
improvements which I would like to suggest:

- generally, whenever the package name/version, e.g., pdb2pqr
 appears in the ebuild, replace it by ${P},${PV},.. (see docs).
- the description should be shorter if possible
- the call to need_fortran f77 should be sufficient, and you don't 
  need the additional build_with_use check. 
  Furthermore, you might already want to think of a way to handle
  the new gfortran that will come with gcc-4.x.
- the local variable myconf in src_compile doesn't do anything and
  should be left out.
- the call to doins propka/*propka* installs f77-source/swig interface 
  files which don't belong there.
- each of the doins calls would benefit from a 'die "failed to install ...."'
- instead of hardcoding python-2.4 you might want to consider 
  inheriting the python.eclass and using the variables (e.g. ${PYVER})
  provided by it.
- make sure to use tabs instead of whitespaces (lines 19 and 49)

Thank you very much,
Markus

Thanks for the constructive criticism! I'll fix the ebuild and submit a new one
when I get time....working in the lab today...
:D

Created an attachment (id=82020) [edit]
ebuild for pdb2pqr

Here's an updated ebuild for pdb2pqr. I think it incorporates all your fixes,
and I'll look into gfortran after I can google up some good information...
je_fro

Created an attachment (id=82074) [edit]
ebuild for pdb2pqr

whoops...forgot python_version...

Hi Jeff,

Thanks for your updated ebuild. I hope I can have a closer look
at it tonight. 

One of the issues with fortran and gcc-4.x is the fact that it
does not provide g77 any more but rather gfortran. Hence, first
of all you should check if the package compiles and works using gfortran.
If it compiles the need_fortran part in the ebuild should be changed
to 

need_fortran gfortran g77

However, if you look at the fortran.eclass you will notice that this is 
the default anyway, hence you can leave the whole pkg_setup() stuff
out. As long as you inherit the fortran eclass it will be executed
automatically.

In case it doesn't compile with gfortran it might be a good idea checking
into what the problem could be.

best,
Markus

Instead of running need_fortran I prefer to set FORTRAN="g77 gfortran" in the
global variables. That automagically takes care of the pkg_setup stuff.

This ebuild also needs to get multilib intelligence -- get_libdir() from
multilib.eclass

Also relative symlinks should be used instead of absolute.

The src_compile is redundant.

Created an attachment (id=82200) [edit]
revised pdb2pqr ebuild

I think I've implemented all the recommended changes. It still works here :D

Hi Jeff,

Thanks and looks nice now. I'll see that I test it soon with
some of my favorite pdbs.

Thanks,
Markus

Hi Jeff,

I just commited pdb2pqr to portage. Many thanks again for your
ebuild and help!

The final ebuild has several modifications from the last one you
posted; please have a look at them:

- even though you specified gfortran in the ebuild, pdb2pqr did
  not compile with it! I had to create a small patch to fix this. 
- the way the files are installed in the python/site-packages 
  directory, pdb2pqr did not "find" the propka stuff and I needed
  to patch the main pdb2pqr.py file to fix this.
- your ebuild still installed much of the content of propka, including
  the source and object files. All that is needed is the *.so and the
  python wrapper, the rest should not end up on the life file system.

Otherwise, great work and thanks again. Please give it a spin once
it hits the mirrors. It seems to work fine for the pdbs I've tried so 
far. I really like the package!

best,
Markus

hmm....maybe I had some leftover propka stuff that wasn't uninstalled and gave
me the appearance the ebuild worked...
anyway, can you add ~amd64 when you can? 
Thanks!
je_fro

(In reply to comment #13)
> anyway, can you add ~amd64 when you can? 

Hi Jeff,

I can't, since I only have a x86 box to test. Gentoo policy is that developers 
should only mark packages ~arch on the architectures they can test and verify
that the ebuild works. In this case, the proper way to have the package marked 
~arch is to file a bug with the respective arch team asking them to test and
do this for you. It is always very helpful to attach a small test example
to assist the arch folks with the testing. In this case this might be a
small pdb file, the command line to run pdb2pqr and the expected
results (in words).

Hence, if you know that the pdb2pqr ebuild works fine on amd64 please file 
a bug with the amd64 herd and they'll take care of it.

Thanks,
Markus