[Pkg-tcltk-devel] Bug#434394: Time to move bwidget under /usr/share?

[Joe English]

> Anselm Lingnau wrote:
> > Francesco Paolo Lovergine wrote:
> > > Bwidget should move its stuff under /usr/share now, it depends on tk8.4
> > > so I see no reasons to maintain it under /usr/lib which is not
> > > appropriate by policy.

Which policy are you referring to?

I'm guessing you mean the FHS.  If so, then AIUI installing BWidget
under /usr/lib is OK since, although it is architecture-independent,
it's still a library.  Similar to things that currently get installed
under /usr/lib/pythonX.Y and /usr/lib/perl/ (at least in sarge, has
this changed?).

> > I agree with you in principle but as long as Debian's wish8.4 does not
> > include /usr/share in its auto_path there isn't much point in moving Bwidge
> > to there as it is not going to be found -- which would make it pretty
> > useless.

Exactly.

> > I'll contact the Tcl maintainers to find out what they have to say about
> > adding /usr/share to the auto_path.

We discussed this this morning on Jabber; consensus seems to be:

    * Nobody could find a anything in the FHS that would
      rule out installing Tcl packages under /usr/lib
      (but we're willing to be corrected);

    * Adding /usr/share to the default $::auto_path would be
      a bad idea, for the same reason that (in retrospect)
      having /usr/lib there isn't such a good idea [*] -- it would
      make Tcl look in even more unnecessary places for packages.
    
    * /usr/share/site-tcl, /usr/share/site-tcl8, or /usr/share/site-tcl8.X
      would be OK though.

    * The maintainers are happy to accommodate downstream packaging
      policies in Tcl's build system, if we can find out what
      those packaging policies are.


[*] Concerning /usr/lib in auto_path -- even though this is known 
to cause problems, it'll probably have to stay -- at least in default
out-of-box builds -- since most Tcl extensions install themselves in
${TCL_PREFIX}/lib by default.


--Joe English