Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#14195 - [openswan] suggest replacing with strongswan

Attached to Project: Arch Linux
Opened by Ray (ataraxia) - Sunday, 12 April 2009, 05:43 GMT
Last edited by Aaron Griffin (phrakture) - Wednesday, 02 December 2009, 18:46 GMT
Task Type Feature Request
Category Packages: Core
Status Closed
Assigned To Thomas B├Ąchler (brain0)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No


I noticed that the openswan package in core is over a year out of date (and that's it's long since been flagged). Since this package has been giving me trouble, I tried updating it to the latest upstream... What a mess. I now see why Tom K hasn't updated it himself.

The build is some kind of custom Makefile setup that's very broken. It doesn't even build various required pieces of the package (like the frontend "ipsec"). The rest of OpenSwan isn't so great either. Documentation is out of date and inconsistent with itself. OpenSwan's website doesn't reflect well of the project, either.

I gave up on OpenSwan and tried out strongSwan. (There's a build in AUR, but it's not of very good quality; I'm attaching the one I came up with to this bug report.) I got strongSwan working in under a day. Docs are up to date and accurate. The build system is standard autotools. There's no silly KLIPS module to care about. Defaults are sensible. The front-end interface is more convenient than OpenSwan's.

I'd like to suggest OpenSwan be replaced with strongSwan, or at least, that strongSwan should be promoted to equal status in Arch. (Certainly I've got an ulterior motive here, as this would move a package I use from AUR to core. Not trying to hide that.)

Sorry if this should have gone into the forum instead; I couldn't figure out what to do with this idea.
   PKGBUILD (0.8 KiB)
This task depends upon

Closed by  Aaron Griffin (phrakture)
Wednesday, 02 December 2009, 18:46 GMT
Reason for closing:  None
Additional comments about closing:  See comments. openswan no longer in core
Comment by Ray (ataraxia) - Sunday, 31 May 2009, 04:22 GMT
strongSwan has been updated since this was opened. Also, it no longer compiles cleanly since the update to glibc 2.10 as it has its own version of getline that goes all the way back to FreeSwan. I've worked around this by renaming the local copy of this function, which is confined to a single source file.

The patch, and a new PKGBUILD, are attached.
Comment by Tobias Powalowski (tpowa) - Sunday, 31 May 2009, 06:49 GMT
i'm not a swan user at all, anyone else might look at this.
Comment by Ray (ataraxia) - Sunday, 14 June 2009, 21:00 GMT
I've adopted the AUR package for strongswan, and updated it to match what I believe would be appropriate for replacing OpenSWAN. (So, it supersedes my previous comment and its attachments.) The only further change I would recommend would be to "replace" and well as "conflict" with openswan - I set conflicts=('openswan') in my PKGBUILD but didn't feel it was appropriate to allow an AUR package to automatically replace a package from core, as that could be a nasty surprise.
Comment by Thomas Dziedzic (tomd123) - Wednesday, 02 December 2009, 18:22 GMT
openswan is not in the main repos anymore. Need to move this to some other bug list.
Comment by Ray (ataraxia) - Wednesday, 02 December 2009, 18:44 GMT
I (the original submitter) would be fine with just closing this. I no longer use any *Swan package, and having the crusty old openswan out of core is good enough for me if nobody else cares.