[Pkg-tcltk-devel] Providing/ maintaining xotcl extension

[Stefan Sobernig]

>> I think that it's a good idea to package xotcl for Debian.
> 
>> Well, just create the package and I'll be glad to upload it into 
>> Debian archive.
> 
> Ok ... I will get my hands dirty and complete it as good as I can ...

I finally finished a first, close-to-ready version of an xotcl debian 
distribution. Find the build/source at:

http://media.wu-wien.ac.at/download/debian

While being prepared for 1.5.6, I am awaiting the XOTcl 1.5.7 release to 
complete the first release candidate to be filed with Debian.

Apart fromt waiting for the upstream release, a couple of questions 
popped up in my mind. They are far from being critical to releasing the 
packages, but why not tackling them at this point ...

1. SONAME of the xotcl extension/ shared library

I was wondering whether to comply with the Debian Policy clauses on 
SONAMEs for "public libraries" is critical to a tcl extension such as 
XOTcl and, if so, how to best realise compliance in the source package.

See http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html

"Public libraries" are those being linked against or being linkable (to 
put it over-superficially short). In case of tcl extensions this is not 
really the case/ a requirement, even if we talk about the xotcl c interface.

Why do I bother? Well, newer releases of dpkg_shlibdeps (shadowed by 
dh_shlibdeps) are more strict and they report a warning if 
deb-dependencies between packages (Depends:...) are checked for linking 
dependencies. See 
http://lists.debian.org/debian-devel-announce/2007/09/msg00004.html. So, 
provided that I include Depends clauses in the xotcl-doc and xotcl-dev 
sub-packages to xotcl, the SONAME libxotclx.x.x.so is reported as 
linking dependency. however, libxotclx.x.x.so is missing the SONAME 
prefix, e.g. libxotcl.x.x.x.so.1 or the like:

> dpkg-shlibdeps: warning: format of `NEEDED libxotcl1.5.6.so' not recognized
> dpkg-shlibdeps: warning: format of `NEEDED libxotcl1.5.6.so' not recognized

I verified in your source package repository at 
http://svn.debian.org/viewsvn/pkg-tcltk/ to find some hints of your way 
of proceeding. In the itcl case, you simply provide symlinks with a 
proper SONAME prefix, i.e. "libitcl3.1.so.1" . However, I got the 
impression that the SONAME should reflect the Debian package version, 
e.g. ...-1, ...-2 etc., at least if I got the Debian Policy right in 
this respect:

What do you suggest?

According to Raphaël Hertzog, the maintainer of dpkg-shlibdeps,
there are three paths to take (taken from:
http://www.mail-archive.com/debian-dpkg-bugs@lists.debian.org/msg05486.html)

> You have 3 solutions:
> - make sure that the lib has no SONAME so that it's identified by
>   dpkg-shlibdeps as a private library

this would mean to rename the xotcl *.so, i.e. strip of the "lib" prefix.

> - add --ignore-missing-info to the dpkg-shlibdeps call (you can pass this via "dh_shlibdeps -- --ignore-missing-info")

this only works with newer dpkg-shlibdeps version (unstable/experimental)

> - add dependency information for this library (shlibs is not possible
>   given that it has no version, however symbols files are possible)

i am not quite sure what this means in our case, i guess, providing a 
symlink to the *.so file exporting an SONAME (?).

Anyway, these are just warnings, the build processes is not hindered by 
those.

2. tcl/tk 8.5 modes of compatibility

XOTcl may come in various compat modes (snippet taken from XOTcl ChangeLog):

a) a native version for Tcl 8.4 (without compatibility layer)
b) a native version for Tcl 8.5
c) a version compiled for Tcl 8.4 with compatibility layer in tclsh8.4
d) a version compiled for Tcl 8.4 with compatibility layer in tclsh8.5

I checked the xotcl package binaries against your tcl8.4 and tcl8.5 
builds and they work fine. However, as for the source package, I was 
wondering whether there is some magic needed/ required to tell the build 
system that xotcl might be build against 8.4/8.5 explicitly. Currently, 
build dependencies are generic, i.e.

tcl-dev (>= 8.4), tk-dev (>= 8.4)

In principle this allows builds against 8.5, however, is there a 
need/requirement to allow it explicitly, by branching on 
DEB_BUILD_OPTIONS etc. in rules???

3. Possible naming clashes of arch-independent packages/extensions 
(Debian Tcl/Tk Policy)

The packages are supposed to comply to the Debian Tcl/Tk Policy 0.2.0:
XOTcl comes with some Tcl packages/modules that are 
architecture-independent/implemented in XOTcl/Tcl. Following
http://pkg-tcltk.alioth.debian.org/tcltk-policy.html/ch-tcltk.html#s-tcltk-dev, 

I re-arranged the default distribution to place those in 
/usr/share/tcltk/... . However, your policy is unclear in one respect 
(or, to put it different: leaves it to the our discretion): The default 
Tcl package require process only diggs immediate subdirectories of 
auto_load paths (though one could hook into package unknown and provide 
deeper recursion). Provided that all goes into /usr/share/tcltk this 
might risk name collision of package directories (those containing 
pkgIndex.tcl). Therefore, I (by convention) stick to the following 
naming convention xotcl-<version>-<package_directory_name>. Hope, this 
is fine. In principle, one could devise an intermediate directoriy, e.g. 
"xotcl-<version>", but this would require amendments to the package 
require process to go one step deeper ...

Thanks for your thoughts ...
All the best

//stefan

-- 
Stefan Sobernig
Institute for Information Systems and New Media
Vienna University of Economics	
Augasse 2-6
A - 1090 Vienna

`- +43 - 1 - 31336 - 4878 [phone]
`- +43 - 1 - 31336 - 746 [fax]
`- stefan.sobernig at wu-wien.ac.at <mailto:stefan.sobernig at wu-wien.ac.at>
`- ss at thinkersfoot.net <mailto:ss at thinkersfoot.net>