[Pkg-tcltk-devel] Questions about backporting tcltk8.6; tdbc, drivers.

[Konstantin Khomoutov]

(I rearranged certain bits of discussion for grouping purposes.)

On Sat, Jul 03, 2010 at 04:47:57PM +0200, tomas at tuxteam.de wrote:

> > After consulting with Sergei Golovan, I have decided to start packaging
> > TDBC as a set of packages separate from tcl8.6 itself
> Well, the version I got hold of (that's tcl8.6-8.6.0~b1) already builds a
> separate TDBC .deb so that seems to be fine. Or did I misunderstand you?
[...]
> > upstream folks will decide to actually bundle TDBC into the Tcl's
> > tarball. This issue has not been discussed with upstream yet but I
> > intend to sort this out.
> Why not just do different .debs off the same source, as it is done in
> tcl8.6-8.6.0~b1?
[...]
> > The current consensus between me and Sergei is to disable building
> > of TDBC stuff packaged in the core Tcl tarball and keep TDBC separate
> > for now.
> Undeerstood. I lack the experience to understand the pros and cons of
> that decision (but I trust you to take the right one ;)

I think I failed to clearly explain this, so let me re-try.

TDBC is ought to be one of so called "core packages". This is a new
concept invented in post-8.5 period and it should not be confused with
"classic" core packages such as reg or http. These "new" core packages
are supposed to counter one of notorious Tcl problems of not having
someone's pet functionality "in the core" -- one classic example is
absence of "core OO" which resulted in some twelve or so implementations,
none of which could be expected to be present on the user's system,
rendering each of them somewhat unusable.

Well, back to the point -- the new concept is to have several "blessed"
big packages and distribute them along with the core, under the "pkgs"
subdirectory. If I understand right, 8.6.0 will be shipped with at least
three such packages: TDBC, Itcl and Thread.

Now the problem: TDBC is being developed independent from Tcl core, has
its own schedule and had several releases by the time 8.6b1 was out.
Every time TDBC is released, it is packaged as a standalone source
tarball (plus archives with win32 binaries and html docs). It's sensible
to package exactly these source tarballs for Debian as each time a new
release is done, we could update the Debian packages and upload them.

Now, it looks like Tcl folks are about (roughly speaking) to include the
contents of what will be the latest stable TDBC release directly to
source tarbal of Tcl 8.6.0. This clearly presents a problem for
packaging as we now have two versions of TDBC sources. To my knowledge,
Debian packaging tools cannot handle this unusual case.
In other words, if we package TDBC from the Tcl tarballs, we're confined to
Tcl's release schedule. If we package TDBC from its own tarballs,
we can follow its releases, but have to not package TDBC which comes
with Tcl. I think the latter is more sensible; at least until TDBC
is mature enough to receive only polishing which could be ignored.

Personally, I would prefer if upstream released 8.6.0 as several
tarballs, like this: tcl-8.6.0.tar.gz, tcl-8.6.0-tbdc.tar.gz etc
with a README file in each satellite package stating something like
"move the contents of this tarball under the directory named ...
under the "pkgs" directory of the Tcl source tree ...".
This would greatly simplify packaging for downstream devs (us) by
eliminating the problem described above.
I'm pondering raising the question about this issue on tcl-core.

As to 8.6b1, TDBC sources included with it simply do not have any
drivers. The reason is unknown to me. Since Sergei is not really
interested in supporting TDBC (he has no uses for it as I understand),
he just packaged what came with 8.6b1 -- no more no less.

> Heh. I'm interested in the PostgreSQL backend (tdbc::postgres). I've got
> it now backported and running. Already stumbled upon what I think is a
> bug, but that's to be expected this early.
I'm building all backends of course (excluding Oracle which is
unfinished anyway).
And it's good that there's someone who can test pgsql backend.