Re: Recent Woody upgrade, TeTeX, XFree86, and Mozilla
On Mon, 5 Mar 2001, Josip Rodin wrote:
> On Mon, Mar 05, 2001 at 06:00:58AM -0500, Dale Scheetz wrote:
> > 2. During the tetex upgrade I was surprised to see the following:
> > texhash: Updating /usr/local/lib/texmf/ls-R...
> > Debian packages are NOT supposed to muck around in /usr/local!!!!!
> I think this stuff is allowed, actually, like that emacs site-lisp whatever
> it is... if anything, several packages do it, it can't be harmful. (Can it?)
Gag me with a spoon!!! Josip, you are usually less in need of clue bat
In every "discussion" about /usr/local the only thing that was _ever_
allowed is the creation of a directory path that the sysadmin might expect
to find there, or find useful. As far as I know emacs site-lisp
directories are created by the package, but their contents is not
This package is recreating hash tables, if I understand things correctly,
and is changing the contents, and possibly even the existance of files in
While I tend to not like even the directories being added (and potentially
subtracted), I can see why we allow that practice. To have this construed
as "it's alright to write over files in /usr/local, 'cause it can't hurt
anything" is a brutally dangerous attitude.
Sysadmins rely on the sanctity of /usr/local to maintain any package or
software program they wish, in any fashion they see fit, without the
package management system comming in at unexpected times and mucking up
> > Config Error: /usr/X11R6/lib/X11/XF86Config:160
> > DefaultColorDepth
> > shared/xfree86v3/config/display/default_depth doesn't exist
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > Default color depth expected
> > I remember choosing 8 bit on a debconf screen, the question is, what do I
> > put in ..../default_depth, and where do I find it.
> I think that's a debconf resource name. Try dpkg-reconfigure xserver-xfree86
> and set it up again (or the xserver-* package you use). And file a bug, I
I had to change two occurances of this string in the config file to the
numeral 8. Once I got the horizontal and vertical sweep rates adjusted
down to something more reasonable to my monitor, I got a working wdm login
and things seem to be OK again, with one exception.
When Potato was released, I noted that I was having some trouble with wdm
restarting the X session sometimes when switching back to X from another
VC. I was told that this was a known bug that would be fixed in the next
release. Well, the next release is here, and guess what: The first time I
switched consoles, after starting mozilla, bam!!! wdm restarts the
server! I guess I can only hope that it will settle down like the last
release did (after a day or two last release, the behaviour stopped. This
is the first time I've seen it in months)
I'd really like a better solution for this, as it is very cumbersom to be
in the midst of a long trail of web page fetches, need some data from a
console VC, go get it, and then find you must go back through all those
links to get to where you were before...
> > Is there any reason that we can't include progeny's version of Mozilla in
> > Debian Woody until such time as our maintainer delivers his release.
> ~~~~~ sid/unstable
> FWIW I agree... so what if the package is not tiptop, it's good enough for
Well, I don't know where you get the "not tiptop" from. The Progeny
release has a working psm and the release in Debian doesn't. Which one is
I'm just greedy, and want the best I can get!
_-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_-
aka Dale Scheetz Phone: 1 (850) 656-9769
Flexible Software 11000 McCrackin Road
e-mail: firstname.lastname@example.org Tallahassee, FL 32308
_-_-_-_-_-_- See www.linuxpress.com for more details _-_-_-_-_-_-_-