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

[Francesco P. Lovergine]

On Sun, Oct 07, 2007 at 01:42:34PM +0400, Sergei Golovan wrote:
> On 10/7/07, Francesco P. Lovergine <frankie at debian.org> wrote:
> > Current sid (8.4.16-1) shows
> >
> > % puts $auto_path
> > /usr/lib/tcl8.4 /usr/lib /usr/lib/tk8.4
> >
> > That was the result with wish at the time of reporting.
> 
> I see.
> 
> > > Since wish tries to find pkgIndex.tcl in every subdirectory of dirs
> > > listed in auto_path adding of 291 directories doesn't look reasonable.
> > >
> >
> > Not to me too, but that because having /usr/lib or /usr/share is silly,
> > we need /usr/lib/tcltk and /usr/share/tcltk and moving there all
> > stuff. I never thought to have tcltk stuff directly under /usr/share :)
> 
> Yes, /usr/share/tcltk looks better. And /usr/lib/tcltk would certainly
> be better than /usr/lib, but (as Joe English mentioned) all existing
> packages are installed into /usr/lib now. Removing /usr/lib from
> auto_path would break every package not included to Debian
> distribution (assuming that all Debian Tcl/Tk packages are moved to
> /usr/lib/tcltk).

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 
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.

The very first step is an agreement about the paths. I would propose simply

/usr/share/tcltk
/usr/lib/tcltk

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

for local installed packages. 

See

http://www.debian.org/doc/packaging-manuals/perl-policy/ch-perl.html#s-paths
http://www.debian.org/doc/packaging-manuals/python-policy/ch-python.html#s-paths
http://pkg-ruby.alioth.debian.org/ruby-policy.html/ch-ruby.html#s-paths

for what other scripting languages do.

> 
> >
> > > I'd propose a halfway solution - to put bwidget scripts to
> > > /usr/share/bwidget1.0.8 and link this directory to /usr/lib. This
> > > technique is used in tcllib now.
> > >
> >
> > /usr/share/tcltk/bwidget1.0.8 would be much more reasonable.
> 
> I agree with you. But if we want to move Tcl-only packages to
> /usr/share/tcltk then we should write a Tcl/Tk policy. Otherwise for
> every new package we will have to file a separate bugreport to move
> the package.
> 

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
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 ...

/o\

PS: I volunteer for writing a first draft if you agree.


-- 
Francesco P. Lovergine