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