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

Re: BALLView: new package version



Hi,

On Mon, Jan 29, 2007 at 02:07:24PM +0100, Andreas Moll wrote:
> again, there a new improved package version available.

I saw this thread now; I tried to package BALL and BALLView for Debichem
a while ago (because WOW the screenshots look great) and took another
shot at it today before seeing your ITP.

I got a few comments on the package (the latest one on mentors.d.n):

 * tetex-* got retired in Debian, texlive and texlive-latex-extra should
   get added as Build-Depends.  However, that still didn't do it for me,
   it failed on fancyheadings.sty, and this doesn't appear to be in any
   package right now.  Maybe we will have to do without fancy headings
   for now.

 * Where do you have the 1.2 tarball from? The official release seems to
   be 1.1.1, and development releases seems to be "1.2 pre 04.07".

 * You should make clear in debian/copyright which parts of the upstream
   tarball you removed (as I understand it, you repackaged it).

 * Can you convince upstream that CF_VERSION_CHECK is maybe not needed?
   You work around it by touching config.lic, which doesn't look very
   nice either (if that code wasn't written by upstream, anyway).  As
   BALL is LGPL, I see no reason to bother the user with a "Yes, I
   agree" kind of stuff similar to Windows EULAs.

 * The way you not just rename upstream's debian/ to debian-upstream/,
   but extensively use it in debian/rules looks very dubious to me; e.g.
   debian-upstream/createBALLVIEWDEB looks very un-debianish to me. I
   really suggest you just ignore debian-upstream; I very much doubt it
   would pass the ftp-master checks for entering the Debian archive
   as well.

 * Priority: in debian/control should be `optional' not `extra' I think.

 * What about the rest of BALL?  Will you package it eventually?  I'd be
   interested in them, but haven't taken a closer look.  You said in an
   earlier mail that there are too many configure options for it, but
   unless there are many conflicting ones, there's lots of precedent in
   Debian - we just turn on the most useful options, and if users
   request further options, that can be thought about as well.

That's it for now, it's getting late :)


Michael 



Reply to: