In article <[EMAIL PROTECTED]> you write: >> > I'm not sure about this, but perhaps you should remove, rather than >> > purge, the xbase package. This is what I did, and I did not get this >> > problem. The difference between purging and removing is that removing >> > leaves configuration files alone, so perhaps purging xbase removes >> > config files necessary to run startx?? >>=20 >> This appears to be the case. I saved my old XF86Config, reran XF86Setup, >> and then replaced the auto-generated XF86Config with my old one. Now >> startx works just fine. > >GACK! I hadn't run across this problem in the versions of XFree86 that >were released in the course of stabilizing it after the Great X >Reorganization. > >Yes, this is a serious problem. I am not sure what I can do to fix it; my >pre- and post- removal scripts in the current xbase package don't delete >those conffiles, dpkg does. It's not easy to change dpkg's mind about such >things.
This sound like the exact same problem (at least it sounds the same) I had when I upgraded from dhcpd to dhcpd-beta. dhcpd wasn't purged, so I purged it, and it broke dhcpd-beta because purging dhcpd deleted /var/dhcpd and /var/dhcpd.leases which are used by both packages. AFAIK, the bug report is still open. dhcpd is a slightly different situation though - I think the postrm script deletes it. However, it is possible that the solution may be similar for both cases, hence my reason for mentioning it here. >Is it the case that somehow the old /var/lib/dpkg/info/xbase.conffiles file >is being left around? On my system, I even still have xbase installed and >it is not there. Is there perhaps some scenario in which the old conffiles >file is not removed? If so, this is probably a bug in dpkg, and not in X. With my very limited knowledge of dpkg. Suggestions: - what package "owned" the config file in question? On my slink system /etc/X11/XF86Config isn't owned by any package. That might be significant. - I assume that XF86Config once was be "owned" by xbase?? - In this case, it might be worth installing an older version of XF86Config, and then reinstalling the new version, checking that everything looks Ok at every step. I don't know if this is possible on slink. - If the above step is not possible, it should be possible to create a dummy package that contains a config file, install it, and then install a newer version that doesn't contain the config file, and see what happens. I think this should reproduce the same situation as with xbase.
