> 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
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
