[TCLCORE] Packaging of "redistributed software" for Tcl 8.6

I intended to raise the question of packaging "redistributed software"
with Tcl 8.6 for some time now as I'm experiencing certain difficulties
packaging TDBC for Debian, and now I see the TIP #376 discussion which
touches quite closely related problems, so I decided to jump in.

First let me state some simple facts about how we (the downstream)
perceive TDBC:
1) TDBC is a separate project (from Tcl), has its own schedule and is
   released in its own tarballs.
2) Downstream packagers (us) work with tarballs. In short, if I decide
   to package TDBC for Debian, I grab TDBC's latests stable tarball,
   "Debianise" it (adding some meta info and a building framework to it,
   fix it to satisfy the distro's policy etc) and then build the set of
   Debian packages from it.
3) Distros (Debian included) quite rarely package "hot" stuff like VCS
   HEADs -- usually distro packages are updated only when a new stable
   upstream version of the particular piece of software comes out.

Constdering the stated facts together brings us to the following
approach to packaging TDBC:
1) TDBC is to be packaged in Debian separately from Tcl as it has more
   frequent releases than Tcl itself and hence packaging it separately
   provides our users with more up-to-date versions of TDBC.
2) We use TDBC's own tarballs.

That's pretty usual approach to packaging stuff, but now we have a
problem: if I understand correctly, the "redistributed software", TDBC
included, is to be packaged *inside* Tcl's own tarball when the next
Tcl version is released. Now we (downstream) have the problem of two
TDBC tarballs. I have no idea how to properly handle this situation from
the point of view of downstream packaging. First of all, there's no way
in Debian to "retarget" packaging from one tarball to another (from
TDBC's own tarball to Tcl's) and then back again when the TDBC makes its
next release. The next question is about whether the version of TDBC
packaged inside Tcl will be absolutely the same as the last released
version of TDBC?
In other words, in Debian we have two alternatives:
1) Do not package TDBC releases when they're done, and just package
   what will be released in Tcl's tarballs. This will work but will
   deny the users from getting fresh TDBC versions packaged (and hence
   tested).
2) Completely ignore TDBC distributed in the Tcl taraball and package it
   as an unrelated project.

Currently we seem to settle on (2) but considering the discussion
followed TIP #376 I would like to provide another possible solution to
this problem: what about dropping the idea of distributing the software
like TDBC inside the Tcl tarball and distribute it *along* the Tcl?
What I mean is switching from releasing one tclX.Y.Z-src.tar.gz tarball
to releasing a set of tarballs, like this:
tclX.Y.Z-core.tar.gz
tclX.Y.Z-tdbcN.M.tar.gz
tclX.Y.Z-itclK.L.tar.gz
and so on.
The core tarball would contain a README file explaining how to unpack
the satellite tarballs and build the software from them.

This approach would solve the problem I stated above since when the new
Tcl release would be made, I'd just grab the tclX.Y.Z-tdbcN.M.tar.gz and
updated my downstream package, and when the next TDBC release would
come out, I'd make the same with its own tarball.

Sure, some people would say this would break that "batteries included"
thing, but let me disagree: that "batteries included" concept is purely
social, not technical. First, people who need "BI" distribution of Tcl
do not build it from the source tarballs -- they download stuff from AS
and then use teapot or they download WinTclTk (now sadly defunct) or
they consider their Linux (or whatever) distro as a one big "BI"
distribution for everything. In other words, they do not care how such
"batteries" are made and whether TDBC sources were really unwrapped from
the Tcl tarball before building or were aquired using some other means.
Second, those who for some odd reason think about source tarballs when
they need a "batteries-included" distribution would just need to
download N tarballs instead of one -- not a big deal provided there are
links to all of them in the official release notes file and a clear
statement about the disposition of these bundles with regard to the
"core" one.

Having said that I must admit I do not oppose the idea of making certain
"redistributed software" "closer to the core" -- that's fine, it's just
creates an unnecessary burden for downstream.

Another way to solve the presented issue would be to just guarantee that
there's always an independent release of TDBC (and whatever) before the
next Tcl release, and the Tcl's bundle gets the unmodified TDBC sources
from that preceding TDBC release (modulo autoconf stuff etc which does
not affect the functionality). This way downstream would be able to
simple ignore everything under "pkgs" which is already being packaged by
other means.

Please note that I would be very glad if the stated problems would
be consedered separately from TIP #376 as that TIP only urged me to
finally sit down and write this text. But on the other hand I think
releasing sqlite as a "separate parallel official tarball" would be just
as fine.


------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Tcl-Core mailing list
Tcl-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tcl-core