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

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

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

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

   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
      This is just waste.

   3. debian/ballview.doc-base
         "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:

     /usr/bin/BALLView              (Shell-script wrapper)
     /usr/lib/BALL/BALLView         (real binary)

     /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)


     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.


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



Reply to: