[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 04:25:58PM +0400, Sergei Golovan wrote:
> 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;

As written below, tons of packages already violate well-stated rules
of debian policy. This is not a reason to refuse to apply a clean
and reasonable policy to Debian packages. Many software out there
also still violate FHS at installation time, but this is not a good reason 
to ignore FHS. This is Debian, not Linux from Scratch or Slackware.

FYI if you check by strace, tclsh issues a stat64() for every shlib
and directory in /usr/lib too. Then check every directory to find out a pkgIndex.tcl
and issues also again a lstat64() for every directory in /usr/lib.
And this is done for every 'package require' instruction! This is simply
not acceptable for me.

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

For perl it is a precise requirement for packagers to move stuff under
standard path defined by policy. This is not done by upstreams.
CPAN packages move all stuff under /usr/local/site_perl generally,
and often package resolve automagically their @INC requirements
by pre-pending the main script directory to standard ones.

Anyway, I'm quite sure any decent tcl scripts generally do not depend
on general prefixes, using some kind of automagic path resolving
in the same way. For instance, all Grass scripts add explicitly their own
multiple roots (/usr/lib/grass/, /usr/lib/grass/bwidget, ...) which
are independent by any tcl initial guess. So what's the point in adding
all the universe to the standard auto_path?

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

These are dedicated to third parties packages, at admin will. They
are there to be useful just-in-case and manage the few cases
in which they could be useful. In any case it is probably better
having that for local stuff, than not (and it does not hurt).

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

Different platforms already have different locations listed
in auto_path, I don't see why that should be of interest for upstream,
maybe it's more appropriate discussing the issue with other linux distributions 
packagers.

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

Ok, general practice is adding an appropriate page to the project web
area. After reaching consensus here it is also appropriate consulting
RMs for an upgrading path. 

-- 
Francesco P. Lovergine