Branden said:

>> Package: xserver-common (main).
>> Maintainer: Branden Robinson <[EMAIL PROTECTED]>
>>   50209 XF86Config moved and config is broken
>
>This appears to be a bug in XF86Setup.  I think it is unlinking its
>target (/usr/X11R6/lib/X11/XF86Config, which for us is a symlink to
>/etc/X11/XF86Config) before writing to it.  I need a Tcl person to
>help analyze the code.

I'm not a tcl person, but I play one on TV. I'm not 100% sure what the
actual "bug" is, but I patched XF86Setup to follow links before it
overwrites things.... here's a patch:

--- xc/programs/Xserver/hw/xfree86/XF86Setup/setuplib.tcl.orig  Fri Jan 14 
03:46:04 2000
+++ xc/programs/Xserver/hw/xfree86/XF86Setup/setuplib.tcl       Fri Jan 14 
04:33:33 2000
@@ -168,6 +168,9 @@
        global pc98 pc98_EGC haveSelectedModes DefaultColorDepth
 
        check_tmpdirs
+        if [ file exists $filename ] { \
+          while { [ file type $filename ] == "link" } \
+         { set filename [file readlink $filename ] } }
        set fd [open $filename w]
        puts $fd "# XF86Config auto-generated by XF86Setup"
        puts $fd "#"
--- xc/programs/Xserver/hw/xfree86/XF86Setup/phase4.tcl.orig    Fri Jan 14 
04:38:59 2000
+++ xc/programs/Xserver/hw/xfree86/XF86Setup/phase4.tcl Fri Jan 14 05:00:23 2000
@@ -56,13 +56,17 @@
        set backupmsg ""
        make_message_phase4 $saveto
        if [file exists $saveto] {
+           while { [ file type $saveto ] == "link" } \
+                   { set saveto [file readlink $saveto ] }
            if {[catch {exec mv $saveto $saveto.bak} ret] != 0} {
                bell
                $w.mesg configure -text $messages(phase4.2);
                return
            }
+           make_message_phase4 $saveto
            set backupmsg $messages(phase4.3)
-       }
+       } else { make_message_phase4 $saveto }
+       
        if {[catch {exec cp $Confname-3 $saveto} ret] != 0} {
            bell
             $w.mesg configure -text $messages(phase4.4)

A note on the patch: it *should* also ask you to save in
/etc/X11/XF86Config instead of /usr/lib/X11/XF86Config, but that's
buried somewhere outside of the XF86Setup code, so I'm not going to
mess with it just now. I stopped tracing things at FindConfigFile,
called from tclxfconf.c, if someone else wants to make that look in
/etc/X11/XF86Config before /usr/lib/X11/XF86Config, but I don't know
where all the dependencies are and what has or hasn't been fixed for
debian already (I patched the vanilla XF86 version, but verified that
the patches go cleanly against my installed debian tcl scripts; I
don't want to deal with getting all of the C source for 3.3.6 right
now... )

The impression I get from the bug report, though, is that the user had
a valid XF86Config file (not link) in /usr/lib/X11/XF86Config, and
when xserver-common_<3.3.5?>.deb was unpacked, it overwrote that with
a symbolic link to /etc/X11/XF86Config, which existed but was bogus,
so he/she lost his/her only copy of the good file.

TCL tends to make me want to throw up... PerlTK and STk are much more
palatable. I can probably make other minor adjustments without turning
too green, if needed, though.

                                :-P

                                        - M

--
Mark "Monty" Montague | [EMAIL PROTECTED]  | I don't do Windows(tm)
       Give me a perl pocket ref, and I'll give you the world.
If guns are outlawed, we'll have to kill each other with cryptography.
                      I'd give C++ about a D-...

Reply via email to