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

Re: BALLView - a molecular viewer and modeling tool


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
So if you like it - just keep it (and perhaps add a README as suggested
There is now a README file in the debian-upstream directory.

   1. As I said I would remove the directories MacOSX and
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
      This is just waste.
You are right and I cleaned up this directory.

   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?
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
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.


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

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:


 if test `echo $PROCESSOR|${CUT} -c3` = ppc ; then
 if test `echo $PROCESSOR` = ppc64 ; then

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
Thank you very much

Andreas Moll

Reply to: