Lo, on Sunday, April 21, Andy Saxena did write: > On Sun, Apr 21, 2002 at 01:46:31AM -0500, Dimitri Maziuk wrote: > > * Sridhar M.A. ([EMAIL PROTECTED]) spake thusly: > > > Hi, > > > > > > Just today when apt-get upgrade installed the new version of > > > xfree86-xserver in testing (4.1.0-16), I could not start X. It was > > > looking for Nvidia chipsets. This appeared strange and on checking I > > > found that the installation script retained almost every entry in my > > > XF86Config-4 file and strangely changed the driver entry from mga to nv. > > > It also removed one of the font paths. Should it not retain the old > > > entries? It was funny looking at the config file: Card identification is > > > Matrox G200, but the driver is nv :-) > > > > If anyone out there still thinks dexconf was a good idea, > > they ought to have their head examined.
Fuel for the fire? Probably. What the heck; here goes anyway. Granted, I've only just recently upgraded from potato to woody, so I haven't been using dexconf all that long. And, I've been reading d-u for a while, so I've had the opportunity to go to school, so to speak, on the folks who met dexconf just after it was released. However, I've really not had any major problems with it. Based on the instructions in the file, I moved my Fonts section outside the DEBCONF region so I could add some additional truetypes, and everything's been fine. I even upgraded the XServer package yesterday; no breakage at all. Based on some of the things that posters here have said, I did back up my XF86Config-4 first, just in case. According to diff, the upgrade changed *two* things in the file: 1) It added some comments explaining the use of dpkg-reconfigure and a reference to the FAQ. 2) It changed my mouse device from /dev/psaux to /dev/misc/psaux. Since I'd previously upgraded from 2.2 to 2.4 and devfs, this was exactly the Right Thing to do. (Course, I've got the old compatibility symlink, so it wasn't strictly necessary, but that's beside the point.) >From what I can see, dexconf is a step in the right direction (but please read on before you start screaming about how it's screwed up your XF86Config file). It provides a way of setting X config options that survives package upgrades, and it *is* optional -- you can remove your XF86Config-4 file from dexconf's control if you so choose. I don't really know how it compares to other X configuration utilities, though: before I upgraded to X 4.1, I used the same old XF86Config file I'd been carrying around for 6 years, so I haven't had to reconfigure X from scratch in a while. However, while the design and intent are valid, the implementation appears to leave some things to be desired. First, while you can remove XF86Config-4 from dexconf's control, it appears that this was not as clear as it could have been early on. Second, based on comments elsewhere in this thread and on the list in general, there appear to be some bugs in dexconf that get tickled during package upgrades. While these may mean that the program was released before it was ready for prime time, they do not necessarily mean that the entire program was a bad idea and should be discarded. Intent != Implementation Design != Implementation (Oh, and Intent != Design as well, but that's not really my point.) Generally, on the programs I write for a living, flaws in implementation are best handled by submitting bug reports. This even works well for many design flaws, too. IMO, complaints about the entire program being a bad thing are only valid if its intent is wrong or if the design flaws are irreparable. Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
