Re: BALLView - a molecular viewer and modeling tool
On Sun, 28 Jan 2007, Andreas wrote:
4. debian/compat
The current debhelper version is 5.x. So if you have no
certain reason (like backporting to Sarge for instance),
I would recommend to use debhelper 5 here.
I used the version 4 because otherwise I could not build the package on
the Edgy Ubuntu. The package works fine with the older version of debhelper.
So if you aware of this fact and have reasons to keep version 4 it
is fine.
perhaps we should write a lintian bug report. The problem:
In /usr/share/BALL/bin and /usr/share/BALL/lib there are binary
architecture dependant files. This is forbidden. The solution
would be as follows:
I fixed the used directories as you suggested.
Fine.
In case the binary expects the doc files at a certain
location put symlinks into this place.
This is still a problem, I tried to create the symlinks, such that they will
be created in the debian/ballview folder, but when the package is finished,
the links are disappeared and instead there are real folders under
/usr/share/BALL/doc.
Do I have to create the links in the
ballview.postinst.debhelper file?
Have a look into
man dh_link
For the moment I would dislike splitting up the package because I guess
it would complicate thinks further. Is there a serious problem with the
current packaging form?
Yes. You should definitely use a binary _any_ package with the
binary dependant part and a binary _all_ package with all files
that work under all architectures (except man pages who are usually
shipped with the binary in one package). The rationale behind is
to keep the ftp archive (and especially bandwidth and space of
the mirrors all over the world) clean of duplicated files that do
not need to be duplicated. There is probably no need to split
up doc and data if the doc is used as online help and is needed
anyway. So this can be put into a ballview-common package, but
using such a package is really high recommended. It depends a
little bit from the ratio of the size of binary and independant
files to make ftpmaster force you to split the package but IMHO
splitting ballview is necessary.
And for the BALL library:
I have thought about creating either an extra development package with the
full
BALL library or a header and static lib dev package.
My guess is that both would not be too useful for the following reason:
The library has around 20 different configure options and thus can be
adapted to differing needs, e.g. by switching features on and off.
Therefore I guess that for every developer that wants to seriously use
the library, it would be better to configure and build the library from
the sources. This also allows to compile and run the tests and
benchmarks.
Well, you are the expert and I have no idea how this optional features
are used. I also wonder if you decide for a certain set of options
whether it will not be possible to provide a development package with
the very same set of options and add a README that if you need different
options you have to compile the development library on your own. But
as I said the developmen package is a bonus and there is no need to
provide it for the first shot. On the other hand I guess people will
ask you for it (I just realized it for the WOrdNet package where I never
expected people to ask for it).
Maybe I am wrong?
Maybe I'm wrong as well. ;-)
I have changed the control file yet an other time to support "any" arch.
Fine.
By the way, Andreas Moll, the PPC architecture name in Debian is
"powerpc" and not "ppc", as in "foo_1.0-3_powerpc.deb", just in case
there was some doubt...
Where is this name used, except for the control file?
I personally have no idea.
Kind regards and thanks for your work on ballview
Andreas.
--
http://fam-tille.de
Reply to: