On Tue, Oct 22, 2002 at 06:00:48PM -0400, Matt Zimmerman wrote: > As I said, I am suggesting we mimick the conffile mechanism. conffiles are > not parsed, but their modification is noticed. My proposed system would not > prevent the user from using the menu-driven configuration; it would simple > offer them a choice about whether to generate a new configuration using the > dialogs, or to preserve their existing configuration. This choice would > only be necessary if the file had been modified by hand.
I think I would probably migrate the XFree86 packages to using this if you implemented it. The more I think about what it would require to completely handle an XF86Config file with Debconf, the less I want to do it. It feels like the wrong direction to be going. Some sections of the file can appear 0, 1 or n times. You'd have to build menus based on the identifiers for various sections and have the user select which one to use. This means I'd be generating questions from templates all over the place, and using the names of debconf questions as values in a select template (this fact could be masked, but it would be happening). It's just grody. I get two kinds of complaints about the debconfization of the X server: 1) I didn't bother to read the top of the config file, or any documentation anywhere, my changes got clobbered, and I'm mad. 2) You don't support this obscure-ass option, and I think you should. With what you propose it would be easier to hew back towards my original intent for the XFree86 debconf templates, which was: Get a working, non-gross, single-headed X configuration going if at all possible so that, with DEBIAN_PRIORITY=high, newbies don't even have to know that there is such a thin as an XFree86 configuration file. I am profoundly disinterested in a full solution. To do it right would be to reinvent xf86cfg, which has to load the driver modules itself to ask them what options they support. That's a horrible thing to be doing in an installation scenario. Especially when the damn package isn't even unpacked yet. Yes, now that I've written this mail, I've pretty much made up my mind. I like your idea. If the user dicks with the autogenerated file, we slam on the brakes and toss him into the manual configuration ghetto where he belongs. His changes are respected and he gets to RTF XF86Config-4(5) page. People have demonstrated to my satisfaction that: ### BEGIN DEBCONF SECTION # XF86Config-4 (XFree86 server configuration file) generated by dexconf, the # Debian X Configuration tool, using values from the debconf database. # # Edit this file with caution, and see the XF86Config-4 manual page. # (Type "man XF86Config-4" at the shell prompt.) # # If you want your changes to this file preserved by dexconf, only make changes # before the "### BEGIN DEBCONF SECTION" line above, and/or after the # "### END DEBCONF SECTION" line below. # # To change things within the debconf section, run the command: # dpkg-reconfigure xserver-xfree86 # as root. Also see "How do I add custom sections to a dexconf-generated # XF86Config or XF86Config-4 file?" in /usr/share/doc/xfree86-common/FAQ.gz. is just a very long way of saying "fnord". People's minds just blot it out and they insist that the text does not exist. They. Will. Not. Read. Matt, I'd be more than happy to use xfree86 in unstable as a testbed for your proposal. If you agree, let's migrate this subthread over to debian-x. -- G. Branden Robinson | Debian GNU/Linux | // // // / / [EMAIL PROTECTED] | EI 'AANIIGOO 'AHOOT'E http://people.debian.org/~branden/ |
msg04212/pgp00000.pgp
Description: PGP signature
