How should I deal with config. file moves?
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 debian-mentors-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: