[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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

This package is recreating hash tables, if I understand things correctly,
and is changing the contents, and possibly even the existance of files in
/usr/local.

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

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

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
not "tiptop"?

I'm just greedy, and want the best I can get!

Waiting is,

Dwarf
--
_-_-_-_-_-   Author of "The Debian Linux User's Guide"  _-_-_-_-_-_-

aka   Dale Scheetz                   Phone:   1 (850) 656-9769
      Flexible Software              11000 McCrackin Road
      e-mail:  dwarf@polaris.net     Tallahassee, FL  32308

_-_-_-_-_-_- See www.linuxpress.com for more details  _-_-_-_-_-_-_-



Reply to: