Re: Build-dependency for rasmol: cbflib
On Thu, Feb 28, 2008 at 4:12 PM, Andreas Tille <firstname.lastname@example.org> wrote:
> [I take the freedom to quote your private mail to Debian-Med list and
> hope you don't mind about ignorance of the netiquette in this special
No problem, and sorry for not following up sooner.
> 0. Think about group maintenance in DebiChem or Debian-Med
> as well.
Group maintenance would be ok, but as mentioned in the ITP (#467655),
I'm not a big fan of maintaining patch stacks under debian/. I will
look into the merge mode in svn-buildpackage and see if I can
integrate it to my workflow easily, but this will take some time.
> 1. If it is a library you should probably follow the library
> packaging guide. This includes providing a package containing
> the dynamical library as well as a -dev package with static
> library and *.h files.
> Hint: The most easiest way to build both is making usage of
> automake and libtools. If you have problems with this
> you could ask on debian-devel. If you decide to do so
> it is a very good idea to talks to upstream about this first.
Policy 8.3 gives three reasons for making static-only libraries.
CBFlib scores two out of these three, namely
* libraries whose interfaces are in flux or under development
(commonly the case when the library's major version number is zero, or
where the ABI breaks across patchlevels)
* libraries which are explicitly intended to be available only in
static form by their upstream author(s)
I think the earliest time to start thinking about CBFlib shared
libraries is when there's another package besides Rasmol in Debian
depending on it.
> 2. I see large chunks of documentation in the source package
> but no separate doc package. I would strongly advise to
> build a separate doc package.
Ok, I'll revise the package soonish.
> BTW, did rasmol upstream accepted your GTK version?
Yes, the code is in the CVS, but maybe not in the next release.