I have just been approved as a Debian maintainer (as in, I've been told I'll get my master account and subscription to debian-private tomorrow) and I've gotten fvwm95. Now, whether you may know it or not, fvwm95 has had a truly ugly configuration up untill now, because of a bug in FvwmTaskBar. (Well, that's where I chopped at code and got it to work; whether the bug was there or in some other fvwm95 code may be debateable).
Anyway, the old style of configuration had one configuration file (aside from menu stuff) - /etc/X11/fvwm95/system.fvwm95rc-menu. This was used by the menu file to generate /etc/X11/fvwm95/system.fvwm95rc - if a user wanted to customize their own look, they had to copy the system rcfile into their own .fvwm95rc and ... Anyway, trust me - it was ugly. Now, what happens is roughly what happens in fvwm2. There are a bunch of *.hook files in /etc/X11/fvwm95/ which get incorporated into the fvwm95 startup through "Read" statements. Each of these hook files is listed as a conffile; further, /etc/X11/fvwm95/system.fvwm95rc is also listed as a conffile. The file /etc/X11/fvwm95/system.fvwm95rc-menu is thankfully gone. Now my question is: how should I handle the transition for people who have modified their /etc/X11/fvwm95/system.fvwm95rc-menu? What I'm planning to do (I got this idea from fvwm2) is in the preinst check whether the system.fvwm95rc-menu has been modified from the version from the previous install, and if so print a warning message saying something like: You've modified you /etc/X11/fvwm95/system.fvwm95rc-menu, which is no longer used. You should edit the /etc/X11/fvwm95/system.fvwm95rc or the new '.hook' files to incorporate your edits. You should then delete /etc/X11/fvwm95/system.fvwm95rc-menu as subsequent fvwm95 installs won't work with it on your system. Also in the preinst I check to see if /etc/X11/fvwm95/system.fvwm95rc-menu is on the system but wasn't part of the previous fvwm95 install. If so I print a message saying "/etc/X11/fvwm95/system.fvwm95rc-menu is on your system but the version of fvwm95 being replaced didn't use it. You should delete and/or move this file before proceeding." - I then have the preinst exit with status 1, causing the install to be aborted. That is, the first install of the "new configuration style" fvwm95 will just print a long error message, but subsequent installs will fail unless /etc/X11/fvwm95/system.fvwm95rc-menu is deleted. This should hopefully force people to clean up obsolete configuration files. Here's my question: should I be forcing people to update their systems like this? Should I just print a warning message and continue in both cases? Should I, as the fvwm2 preinst script does, issue a "press RETURN to continue" prompt in the preinst, or should I obey policy and not prompt the user in the preinst? Should I check for other obsolete configuration file names? (since the names of all fvwm95 config. files changed from *.fvwm2rc95 in bo to *.fvwm95rc in hamm.) Also, what are the guidelines for whether a new package version should go into frozen (hamm) or into unstable (slink)? On the one hand, this package incorporates previously untested code, and should probably go into unstable. On the other hand, I could see that an easily configurable fvwm95 might be an important thing to have in Debian 2.0 - who decides questions like this? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
