I also suggest, given the violent reactions of some people to the prospect of losing fvwm 1.x: The existing fvwm package can be reproduced as an "fvwm1" or "fvwm-classic" package, which you can give to someone else to maintain (or orphan) if you desire. If there is a new release of fvwm upstream that is declared stable by its (upstream) maintainers, I see no reason that we should fork a new package for it. *IT* should be contained in the "fvwm" package, no ifs, ands, or buts. Including the version number in the package name makes sense for shared libraries, and it may make sense for things that are practically operating systems all by themselves (like the emacsen), but this is just a window manager (albeit a very popular one). We don't fork off a new package name at the drop of a hat just because people like the old stable package. I *do*, however, agree with the sentiment that the fvwm1rc-to-fvwm2rc converter NOT be run automatically on users' files. There are too many risks, and it is just plain rude for the system administrator to modify the contents of user home directories anyway. The best thing to do in such situations is just to put a message in /etc/motd, and/or mail all users about the change, but that's not something the Debian package should do. I recommend leaving the converter around for users to employ at their own risk. -- G. Branden Robinson | I am sorry, but what you have mistaken Debian GNU/Linux | for malicious intent is nothing more branden@ecn.purdue.edu | than sheer incompetence! cartoon.ecn.purdue.edu/~branden/ | -- J. L. Rizzo II
Attachment:
pgppek3wmb8Z7.pgp
Description: PGP signature