Re: BALLView - a molecular viewer and modeling tool
Hi,
I have created a new version of package, that takes into account the
following points:
2. The debian-upstream directory is a really interesting
alternative to something we do not really like if upstream
provides a debian directory. I have to clear up my mind
whether I wil like it or not. ;-)
*g* Well, I like the idea, since our upstream authors, can develop
install routines, that can be used by future downstream authors as
well.
So if you like it - just keep it (and perhaps add a README as suggested
below.
There is now a README file in the debian-upstream directory.
1. As I said I would remove the directories MacOSX and
Windows.
Like you suggested, I have removed the unneeded folders from the tgz.
What I would definitely remove from the tarball in any
case are the files that would have been cleaned after
make -f debian/rules clean
like
debian-upstream/{deb-ball-source,ballview.substvars,files}
This is just waste.
You are right and I cleaned up this directory.
3. debian/ballview.doc-base
Quote:
"This manual describes what ballview is and how it
can be used."
Uhmmm, I guess the packaging is not really finished, right?
;-))
Well yes, I forget to add the actual description ;)
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.
Now for the package builded. It is lintian free which is good,
However I guess lintian is not perfect in detecting everything -
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.
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?
As a result of this problem, in the current version of the package, the
inline documentation is not working, since the program can not find
the corresonding HTML files.
Perhaps it is worth
thinking about splitting up the doc into a doc for the
plain BALL library and BALLView itself. In case it might
happen that users might use the BALL library for something
else this would make sense.
ballview-lib_1.2-1_<arch>.deb
/usr/lib/BALL/*.so
And for the bonus track (and here you can probably get help from
the debian-devel list: Try to patch the source to use libtool and
provide a devel package with the static library and header files.
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?
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.
Maybe I am wrong?
> If there is no reason to exclude a certain architecture you should
> always use "Architecture: all" in your package.
I'm pretty sure you meant to say "Architecture: any" here.
I have changed the control file yet an other time to support "any" arch.
I hope that this was not to much for the first shot.
No, I am glad that I get so much feedback and can thus do a better
packaging job. ;)
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 have still one problem: Recognizing the PowerPC architecture.
Currently the corresponding section in our configuration files looks like:
PROCESSOR=`${UNAME} -m`
if test `echo $PROCESSOR|${CUT} -c3` = ppc ; then
ARCHITECTURE=ppc32
BINFMT=Linux-ppc32
fi
if test `echo $PROCESSOR` = ppc64 ; then
ARCHITECTURE=ppc64
BINFMT=Linux-ppc64
fi
Unfortunately I am not sure if I got the names right, i.e. I dont
know if uname differs between the 32 and 64 bit processors.
Could some of the PPC users please send me the corresponding uname
output?
Thank you very much
Andreas Moll
Reply to: