Hi all, [Please CC me in replies, I am currently not subscribed to -devel. This is also cross-posted to debian-user because it might affect users that are not subscribed to -devel.] I have thought for quite some time about this issue and have now come to a decision. Sorry that it's rather late in the release process, but I really think it'll be better this way. If nobody wants to argue in favor of it, I hereby request freeswan to be removed from the archive (unstable and testing). (Please read further before actually doing it or starting to flame. Thanks.) Reasoning: freeswan is dead. It's upstream development has been discontinued, it has a lot of open bugs in the Debian BTS that I sometimes can't and for others won't fix. Besides all of that, the freeswan package has always been a bloody mess, with sometimes >10 (usually conflicting) patches needing to be applied to get all the features necessary for today's IPSec demands. Yes, package updates to new upstream version have not (only) taken that long because I am lazy. But don't despair, a new contender is here for rescue: openswan. It is a fork of the freeswan codebase, but already integrates most of the third-party patches I have been applying to the Debian package over the last years. It is therefore more feature-complete than native freeswan ever was. Since quite some time, I am also packaging openswan, and for nearly that long it is also in the Debian archive (unstable and testing). I am a lot more happy with my contacts to openswan upstream than I have been to my contacts to freeswan upstream (although some of them simply moved from freeswan to openswan). I can't give some facts here, but the openswan team is extremely responsive to any requests, which I like very much. In fact, most of the time the upstream package will include the latest Debian packaging, so the .diff.gz is generally _very_ small. One of the best points for openswan, from a user point of view, is that it is config-file compatible. I.e. if you remove (not purge) freeswan, install openswan, and - if you use the KLIPS kernel part instead of the native Linux IPSec kernel stack - recompile the kernel (or the modules) with openswan instead of freeswan, no other changes should be necessary. The same ipsec.conf, ipsec.secrets and X.509 certificates can be used. To make a long story short: If you have any compelling reason to continue using freeswan, i.e. if for some reason you can not use openswan, then please let me know now. And no, not wanting to compile a new kernel because of the switch is not a compelling reason. If you can't recompile your kernel, you either a) shouldn't have compiled it in the first place or b) should not be running unstable or testing. Remember that nothing will change for stable. I am probably being presumptuous with regard to current freeswan users here, but I am looking for the best solution for users of the to-be-stable release, and freeswan is not good for that. Better a clear cut now. If there are no objections within 2 weeks from now, I will ask the ftp maintainers and release managers to remove freeswan from unstable and testing. I am still thinking about doing an "upgrade" package of freeswan though, which depends on openswan and simply moves the configuration of the old freeswan configuration to openswan. Any preferences towards such a package? with best regards, Rene
Attachment:
pgpEdx0oc788T.pgp
Description: PGP signature