Re: Pakaging Staden for Debian
On 2 Jul 2007, at 7:51 pm, Andreas Tille wrote:
When I tried to build the package I was hit by several problems
that are caused by the fact that you relay on certain libraries
beeing in the source path instead provided at usual places where
Linux distributions normally provide this stuff. I was able
to circumvent this by certain patches but I stumbled uppon an
issue that is not consistent in documentation and code.
README.build says Staden would need
* itcl (tested with 3.2.1)
but the file src/mk/global.mk says
ITCLSRC = $(SRCROOT)/incrTcl-3.3cvs/itcl/generic
ITKSRC = $(SRCROOT)/incrTcl-3.3cvs/itk/generic
ITCLVERS = 3.3
ITKVERS = 3.3
which seems to be a clear reference to the not yet released CVS
release of ITCL (which by the way does not seem to be actively
developed any more). So I wonder what is the reason for this
discrepancy.
I suspect a missed update to the README.build, but I'll leave James
to comment in detail.
If Staden would really need itcl 3.3cvs I would be
in trouble because it is not yet packaged for Debian (and I have
no idea how good are the chances that it will be available soon).
I spoke to James about this, and the situation is worse than that.
Not only does it require this particular version of incrTcl, but the
build system then downloads and applies a patch to it; this is a
patch that James supplied to them, but which they have not
incorporated into incrTcl upstream. So even if the incrTcl upstream
were to release their current CVS code base as a formal release, it
would *still* need to be patched before it would work for Staden. :-)
In case it would be a simple patch to version 3.2 I could probably
ask the Debian maintainer of this package to apply it to the
stable version.
It is of course not unheard of for Debian packages to use CVS
checkouts rather than formal releases, although you'd need to both do
that, and persuade the incrTcl Debian maintainer to include James'
patch as well.
Moreover I wonder what might be the sense of the separately
provided tarball of io_lib. For some purpose this lib would
separately solve some of our problems here, but it is confusing
to have different versions around - one bundled in Staden and
one separately.
If you ask me, it would be a good idea to
provise io_lib only separately and give according hints in
the Staden build instructions.
I suspect this is the same rationale as using the built-in version of
Tcl - this is a version known to work stably with Staden.
Regards,
Tim
--
The Wellcome Trust Sanger Institute is operated by Genome Research
Limited, a charity registered in England with number 1021457 and a
company registered in England with number 2742969, whose registered
office is 215 Euston Road, London, NW1 2BE.
Reply to: