Re: FVWM 2.2 officially released
> 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
I've only just adopted it! But as I said in another email, I only
intend to deal with Debian-related bugs. fvwm 1.x is archaic -- fvwm 2.x
has been in preparation for ages.
> 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
OK, I agree. That's what shall be done.
> 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
> 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.
It's not -- Vincent made sure of that.
> 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
It shall be.
Julian Gilbey, Dept of Maths, QMW, Univ. of London. J.D.Gilbey@qmw.ac.uk
Debian GNU/Linux Developer. firstname.lastname@example.org
-*- Finger email@example.com for my PGP public key. -*-