[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Removal of freeswan from sarge

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: 
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 
a) shouldn't have compiled it in the first place
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 

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,

Attachment: pgpLn1wgSvrp7.pgp
Description: PGP signature

Reply to: