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

Re: Pakaging Staden for Debian

[James, I see nothing private in your mail and I know that several
 people in Debian-Med are interested and perhaps more educated than
 me, so I keep the list in CC.]

On Tue, 3 Jul 2007, James Bonfield wrote:


Hello Andreas,


I would like do it "the Debian way" and provide real Debian
packages from this great and important project.


Packaging it up sensibly would be a good thing to do, but time is my
biggest limiting factor at the moment. In the past the package had its
own quirky build system for several reasons, not least of which was
(and is) Mac and Windows support using their native compilers.  The
Mac port was massively simplified when MacOSX came along though.
Windows too is easier now if we just stick to mingw instead of MS
VC++, although the code produced isn't so fast.


Just to make sure that I understand it right: Would mingw work with
autoconf / automake stuff.  I have no idea about Windows and thus I'm
asking.


These factors, along with a deep hatred of all things libtool, meant
we used our own Makefile system instead of autoconf. Maybe it's time
to change though, but to something avoiding libtool for shared
libraries as I still hate it as it's still a royal PITA to debug with
and frankly it's not as portable as it used to be anyway (we've had
problems with it on HP Alphas before).


There are probably different experiences.  Mine - in connection with
sane advises from debian-devel list - were not that bad.


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.


Part of this was due to the fact that we got bit several times by
versioning issues. It takes a huge amount of effort to test the
package works with all the various versions of software and history
has shown us that we can't rely on that either. So we decided, when we
were in the dark days of providing prebuilt binaries only for groups,
to basically wrap all the dependencies together in a single directory
and use wrapper scripts that set LD_LIBRARY_PATH to pick up our own
copies. It's still not a bad solution given the wealth of different
linux distributions and versions of them, but admittedly it doesn't
fit nice.


I have to admit that I have no experiences with other distributions.
I have heard on debian-devel list that libpng caused certain trouble
in the past which should be sorted out now.  I never herad of problems
with zlib and tcl/tl should be reasonable stable.  I personally guess
that itck and iwidgets might be the weak part and I have the very
personal suspicion that it is caused by the fact that developers
drift from these tools from the early days of UNIX to something else
like Gtk+ or Qt and wrappers around these.  So it just turns out that
development on these tools is not dynamical enough any more.  Well,
this does not mean that this would be a reason to switch to a different
toolkit for Staden if it is working - but this just might turn out as
a reason why itck and iwidgets support will became worse in the
future.


That said, the above is really an issue of distributing prebuilt
binaries and it doesn't need to impact on the source system at
all. Separating the two out is probably a good thing.


I would be definitely in favour of this because packaging would
be only possible if we do not provide copies of different versions
of existing software.  We just have to work out whether the existing
libs are working and if not how to get working versions into Debian.


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


The README is almost certainly out of date then. Sorry.


Well, no problem - it's certainly not the only out of date doc I have seen. ;-)


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


Hmm interesting. It looks like that's some relic! You'll unfortunately
find lots of those - the package dates back 25+ years! As far as I can
see the ITCLSRC and ITKSRC isn't really used. It's the installed
paths (ITCL_LIB) that matter.


That's fine because it means two lines less to patch. ;-)


Iwidgets though, now that's a total different kettle of fish. It too
suffers from the same problems as Itcl in that the developers are
still making small changes here and there, but they haven't actually
packaged the CVS tree up to produce an official release for many
years, and worst still the last official release is still somewhat
buggy.



From a Debian point of view the question is: It is better (especially

regarding stability) than the released 3.2.  What are the reasons that
you explicitely are requiring this version: Is the reason an extra feature
you need or it is rather that bugs are fixed.


When itcl3.3 was released (well, 3.3 "release candidate" - 2 years
later and it's still a candidate) it broke the iwidgets build
system. I patched it and submitted a patch. The Makefile.thirdparty
hack then downloads both iwidgets source and also the patch. Messy,
but it gets the job done.


Normally it is no problem to integrate a patch into a Debian package
if it fixes a problem - so if this is necessary for you to have this
patch in a future 3.3 Debian package chances are not bad.


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.  (Meta-hint: I think using a
generic name like io_lib is a very good idea because it
is kind of specific io that is done by this lib and files
like libread and libmisc are also not really good names to
prevent name space pollution.)


Agreed on both points (assuming you meant is NOT a very good idea with
the io_lib name).


Yes.  I guess there are more Input-Output-Libraries out there that
are named like this (I don't know whether all Google hits point to
different flavours of your code.  Specifying what exactly is readed
and written would be the first target I would tackle in case I would
do a general rework of the code.


Io_lib is an appallingly named library and even
worse for the fact that the main data structure within it the "Read"
struct.


At least it is consistently named. ;-)


The reason io_lib is external to the Staden Package is it has
a wider audience


Yes, this was my main point why I came to Staden.  I (or rather my
colleague) needed it.  IMHO this would be a very strong reason to
separate it from Staden package and if you ask me it would be a
much better starting point from a packaging perspective.


I wouldn't want to remove it from the Staden Package though unless I
got io_lib building shared libraries. I did at one stage use libtool
for this and was planning going down that route, but it caused many
more problems than it solved, especially on windows,


This might be a problem because using libtool was my very first idea
when I looked at the tarballs.  I managed to turn more than one library
package to build dynamic and static packages (for the development
packages that also contain headers) to libtool and thus my experience
was not too bad - but I never tried it on Windows.


so I backed out
of those changes. We can't just ignore Windows either. Hate it or not,
there's more than 3x Windows download of the staden binaries than
there are x86 linux ones.


I for myself do not hate anything.  There are just things I do not
understand and thus I stay away from this - Windows is one of these
things.  So I perfectly accept your premise - I just have to relay
on others whether libtool might work there.


That said, there is still only one master location for io_lib - the
src/io_lib directory in CVS. It just happens to be wrapped up in two
different ways when I build source dists.


If you ask me I would change this and would do only a single
separated release.


Further questions are: Are you able, interested and willing to work
together with the Debian-Med people to get Staden packaged for
Debian?  We would like to make the work of people working in
microbiology as easy as possible and perhaps making Staden more
popular in the Free Software world.  This might increase the
chance to get some co-developers for continue the work on
Staden.


To be honest, it depends who does the work and how anal they are
:-).


Concerning my own effort on this it partly depends how far I'm able
to spend time in my working hours on this.  It is certainly no project
for some hours in your spare time and thus my answer is: It depends
whether I'm able to work on it.


Put simply, it's on my to-do list, but it's been on it for years
and given the current work load it's likely to stay on it for some
time still unfortunately. We used to have a group of 5 people
maintaining this and now it's just me part time so unfortunately
things have slowed down somewhat.


Just a random idea: What about trying a Summer of Code project for
the next Google summer of code?


However if someone else wants to
tidy it up I'd be happy provided they're pragmatic and don't end up
with a build system tied only to one distribution,


This is definitely not the intention of Debian packaging.  Normally
building a Debian package tends in more portable and wider usable
software.


or even to
something which no longer builds under MacOS X and Windows with
MinGW/MSYS. We took the decision long ago that we'd only support
windows/mac if we had one single source tree and build environment
that worked for all, otherwise they were destined to diverge. So I
want to keep it that way. That makes it a bit awkward too.


I think this is a perfectly reasonable decision.


PS. I did take a very brief look at PMK recently with the intention of
working out if there are alternatives to libtool. It looks like the
openoffice team make extensive use of it. However I haven't checked it
out fully yet.


I have to admit that I have not even heard about PMK.

Kind regards and thanks for your detailed explanation

       Andreas.

--
http://fam-tille.de
Reply to: