[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFS: libmesh



Hi Alan,

thanks for looking at that. Here is the new dsc:

http://mentors.debian.net/debian/pool/main/l/libmesh/libmesh_0.6.0~rc2.dfsg-1.dsc

The package is now lintian&linda clean, builds fine in pbuilder.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=426734 seems to have
appeared now.

Fixed.

This doesn't look terribly portable (what's it going to do on hurd??) to me:
        ls lib/i486-pc-linux-gnu_opt/*
        cp lib/i486-pc-linux-gnu_opt/libmesh.so $(meshbin)

($shell gcc -dumpmachine) might be what you're looking for?

Actually, I had to use:

grep "hosttype " Make.common | cut -d "=" -f 2 | cut -c 2-

because the hosttype variable in Make.common (generated after the
configure is run) contains the correct path (the gcc -dumpmachine
doesn't).

Also section 1 of [1] is relevant here too I think, in that (your rules
at least) don't look very versioned to me.

Do you mean 8.1? I tried to fix that, please tell me if it needs some
more improvements.

It's also generally better to use install or even dh_install instead of cp

I didn't play with dh_install yet. I'll do it in the next iteration -
I should also include the examples in the debian package and some
instructions how to compile them. So far I only put some documentation
into the README.Debian.

#       dh_makeshlibs
This line needs to be uncommented. This will go someway towards fixing
the lintian problem. People also like complaining about all the
commented lines left in from the template you used. E.g. there's no
point having #dh_installpam hanging around in your debian/rules

Fixed.

I noticed the following: "/usr/bin/make -j2" I don't think parallel
building is considered the done thing in debian/rules, at least that
seemed to be how I remmeber the discussion in [0] going. People don't
like the smaller buildds getting hit like that.

Fixed.

I haven't looked over the dfsg-ness yet. I think it's considered good
practice to document somewhere what had to go and why to make it dfsg.
Either way it'd be quite handy for me. Is it algorithm that's non-free?
Or documentation?

See debian/copyright. Basically, the upstream tar.gz contains some
packages, that are non-free. The rest is free however, so I would like
to have it in the main distribution.

I'd quite like to see libmesh in Debian, as my own work seems to be
heading more and more towards numerical solutions of PDEs and libmesh
looks like it's worth trying out.

Yes, libmesh is a good library. Only their build system and the way to
compile your own programs is nonstandard that's why I decided to
create a debian package for it. Now it can be used very easily as any
other C++ library.

 I'll take another look over the package again later for you. Feel free
to ask more questions if you like :-)

I do :) :

* Currently, it only places libmesh.so.0.6.0 into /usr/lib. So should
I just put  symlinks to libmesh.so into the debian/rules? Or what is
the correct way of handling this?

* The ${shlibs:Depends} in debian/control doesn't produce the
dependency on petsc2.3.2. I can put it there by hand. But isn't it
supposed to do it automatically?

If you have some more suggestions, please let me know.

Ondrej



Reply to: