Re: BALLView - a molecular viewer and modeling tool
On Fri, 26 Jan 2007, Andreas Moll wrote:
I have uploaded a new version of the package.
Well, I checked your work offline and my comments are concerning
the version from tomorrow morning. So feel free to ignore issues
that might be voided by your new version.
I have changed the control file again, to support the ppc arch.
If there is no reason to exclude a certain architecture you should
always use "Architecture: all" in your package. It is not necessarily
your problem if it fails running on this architecture. Your task
is to deal with the bug reports of users of this architecture later.
In the end this will lead to better upstream code (or to the fact
that one architecture has *really* to be excluded if there is no
way out).
Looks interesting, but I can't play with it, as it requires python 2.3.
Huh, where does this 2.3 dependency come from? Builded on a
not upt to date machine?
This issue is fixed in the new version, I have set the build dependency to
python-dev instead of python2.4-dev.
OK - that's right.
1. I would repack the tarball and leave out the Mac OSX and Windows
directory. It is useless burden to the ftp archive
I tried, but failed miserably ;)
I deleted these folders in the extracted upstream package, but build-package
just printed some warnings that it will ignore the missing directories.
Do I have to manually create a new orig.tar.gz without the mentioned folders?
Yes. Building a new tarball means unpacking the upstream tarball,
removing things you want to remove and build a new tarball that
replaces the original one.
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.
Bug#407665: ITP: ballview -- Molecular viewer and modeling tool
Changed Bug title.
I got this email from the Debian bug tracking system and I am not really
sure what it means? Did someone tagged my package for usage in the med-bio
project?
Yes, I did so. Just to keep it in focus of our project - nothing
else.
Now for the text I prepared offline:
Please note: The first things I write are *recomendations* in
the direction I *personally* would do the packaging. If you
have reasons to keep it as is - feel free to do so.
1. As I said I would remove the directories MacOSX and
Windows.
2. To the debian-upstream directory: I often elaborated
on the drawbacks if upstream provided a debian packaging
directory (if needed I try to find some links). The
debian-upstream directory might show the fact that
upstream is aware of these problems and provides this
directory just as a nice comfort for the Debian
maintainer. An additional README explaining this would
be nice.
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.
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?
;-))
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.
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:
/usr/share/BALL/lib/* ----> /usr/lib/BALL
/usr/share/BALL/bin/* ----> /usr/lib/BALL
These files have to go onto a architecture dependant package.
You also have to adapt the shell script in /usr/bin according
to the changed pathes. This is absolutely required and the
package has no chance to pass ftpmaster in the current form.
So if I would be the maintainer of the project I would build
the following packages:
ballview_1.2-1_<arch>.deb
/usr/bin/BALLView (Shell-script wrapper)
/usr/lib/BALL/BALLView (real binary)
/usr/share/man/man1
ballview-data_1.2-1_all.deb
/usr/share/BALL/data
/usr/share/BALL/PYTHON (I don't think that you have
a big deal with Python policy
here because they are simple
scripts no reusable modules)
ballview-doc_1.2-1_all.deb
/usr/share/doc/ballview/html/BALL
/usr/share/doc/ballview/html/BALLView
In case the binary expects the doc files at a certain
location put symlinks into this place. 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.
I hope that this was not to much for the first shot. If you
have no idea how to work this out you might ask here on this list.
The best way to learn about multi binary packaging would be
to have a look into other peoples multi binary packaging. I
don't know whether it is an optimal example, but I'm doing
very similar stuff in the wordnet package.
Thanks for the fine work in any case
Andreas.
--
http://fam-tille.de
Reply to: