FreeTDS Development Group

["ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com>]

> 
> On Thu, Sep 08, 2005 at 07:52:52PM -0400, James K. Lowden wrote:
> > Ben Gribaudo wrote:
> > > Do you have an 
> > > idea as to when 0.63 will be released as a stable Debian package?
> 
> > No, sorry, we don't control that.  We release the code; how 
> it's packaged
> > is up to the packagers.  
> 
> > I have a lot of respect for the Debian project, and I can 
> understand the
> > impulse to rely only on stable precompiled packages.  I 
> think, however,
> > you need to make an exception for FreeTDS, at least for 
> now.  Debian has
> > lately been laggardly in updating its FreeTDS package, ever 
> since its
> > maintainer was kicked upstairs.  (Steve's the release 
> engineer nowadays, I
> > believe.)  The 0.61 version you began with is sooo out of 
> date we don't
> > even want to think about it.  
> 
> Yeah.  Sucks, but there was just no way for me to manage the library
> updates for freetds while also trying to manage... everyone else's
> library updates. ;)  We're at 0.63 for etch, though, and with 
> luck I'll
> be better able to keep on top of updates, at least until etch goes to
> freeze.
> 
> > I think your options are: 1) Complain to Debian and wait, 
> or 2) roll your
> > own.  
> 
> Waiting would mean waiting at least a year until the next stable
> release; there's no way to get FreeTDS 0.63 into sarge, particularly
> given the library soname changes.
> 
> But there are FreeTDS 0.63 packages in Debian unstable which should
> build just fine against sarge as well.  I have no intention 
> of providing 
> pre-built backported packages, though, so I'm afraid you're 
> on your own
> wrt security support unless you can find someone else interested in
> backporting.
> 
> >  > sqsh should work fine, too, after you re-link it.  Does 
> ldd(8) report that
> >  > sqsh is linked to the 0.63 shared objects?
> > I upgraded to the latest stable release from freetds.org, 
> installing it 
> > to the default path (/usr/local, which is different from the usual 
> > Debian way).. ldd's output is below. I'm not sure how to 
> check for what 
> > you mentioned.
> 
> > I still get a segmentation fault when selecting a result set which 
> > contains a datetime column. Any ideas?
> 
> > ldd /usr/bin/sqsh
> >        libct.so.1 => /usr/lib/libct.so.1 (0x4001b000)
> >        libtds.so.2 => /usr/lib/libtds.so.2 (0x40042000)
> 
> Yes, this shows that sqsh is still linked against the freetds 0.61
> version of the libraries.  You'll need to rebuild sqsh as James
> mentioned in order to get it to use the new libraries.
> 

Many things changed after 0.61. There was many reasons why we changed
soname:
- function declarations did not follow proprietary libraries causing
many changes in user code
- some constants was not valid (like a valid value for special value)
- some behavior was just wrong
All this stuff require some user program change (although minor) so is
better to change soname.
What should we do in the name of binary compatibility? Mantain more
function versions and code with wrong behavior? This would require a lot
of work. We don't have thousands active developers like linux kernel, we
have just 3 active ones...
Even backporting is a huge work (many parts have been rewritten),
backport from 0.64 to 0.61 (and why not 0.62 and 0.63) IMO would require
more work that updating all dependency library to 0.63...
I think that we also did a big error packaging FreeTDS. If we can think
about a binary compatibility for dblib/ctlib/odbc is very hard that
libTDS would not change... the error is that freetds package very often
contains libtds.so and libct.so/libsysdb.so libraries, so is hard to
update package (libtds soname change frequently).
For sarge we have few options:
- update freetds package with all dependency. huge work but IMHO with
best results
- provide a new set of duplicating package (freetds2, php-tds2 or
similar). ugly but works
For future stable versions I would suggest:
- use 0.64 directly, I know we don't declare it stable but I think it
will be the stable many time before future debian version
- split libtds.so in another package (dblib/ctlib/odbc so libraries are
not dependent from libtds)

freddy77