[Pkg-tcltk-devel] Time for a policy? [was Re: Time to move bwidget under /usr/share?]

[Sergei Golovan]

On 10/7/07, Francesco P. Lovergine <frankie at debian.org> wrote:
>
> The solution is a mass bug filling, a few NMUs and pre-coordination
> with RMs to having it as a release goal for Tcl/Tk team. Packages not
> included in Debian - sorry - are not a problem of ours. There are

I don't agree with you in that it's not our problem. If we remove
/usr/lib from auto_path then
  1) all users will get many packages broken, and will go to their
authors with complains;
  2) the authors of the packages will hate Debian for these bugreports.

> already TONS of different conventions used out there to install
> stuff for tcl/perl/ruby/python which are very little complaining
> with our debian policies.

I don't know about perl/python, but for Tcl most packages simply drop
pkgIndex.tcl into a subdirectory of /usr/lib. I don't know if any of
the packages really uses TCL_PACKAGE_PATH from tclConfig.sh.

>
> The very first step is an agreement about the paths. I would propose simply
>
> /usr/share/tcltk
> /usr/lib/tcltk

Looks OK to me. Though there are packages (at least package - tclx8.4)
which don't refuse to load into inappropriate tclsh and segfault it.

>
> for any third-party extension/package, without distinction among
> Tcl, Tk and/or versions.
>
> I'm not sure if it is viable also pre-pending
>
> /usr/local/lib/tcltk
> /usr/local/share/tcltk

To install a package to these directories, one has to modify an
installation procedure for every package. I'd expect these directories
to be always empty.

I think we need to discuss removing /usr/lib from auto_path with
upstream developers.

>
> I think this is the way to go. Not having currently a policy is not
> a good excuse to avoid a thing that should be done. Having /usr/lib
> and/or /usr/share in the auto_path is truly bad. We need to coordinate

I'm still not sure if removing /usr/lib from auto_path isn't too costly.

> with RMs for that and a mass bug filling for a few packages (and some of
> them are directly under control of people on this list I think).
> Folks, let's work as a Tcl/Tk Team, not like an abstract concept.
>
> And of course, it's time to startup a policy, I think Tcl is the only
> main stream language which lacks one (at least a draft).
> We should go and hide ...
>
> PS: I volunteer for writing a first draft if you agree.

It would be great!

-- 
Sergei Golovan