Comment 10 for bug 1266066

> The packaging does have extensive lintian errors, 137 instances of
> unstripped-binary-or-object and one spelling-error-in-description.

Packages are not stripped to enable the http://wiki.strongswan.org/projects/strongswan/wiki/IntegrityTest suite.

> Which of the many packages do you need in main? Just strongswan,
> libstrongswan, strongswan-ike, strongswan-plugin-openssl, and
> strongswan-starter? (those are the packages that get installed with
> "apt-get install strongswan")

Ideally, I'd like to see a lot more than that; a bunch that come to mind are: lookip, pkcs11 (smartcard backend [and we know from experience how much fun openvpn is with smartcards]), and the TNC (http://wiki.strongswan.org/projects/strongswan/wiki/TrustedNetworkConnect) components which can tie into Secure Boot.

> There are a lot of debconf questions and you say that strongswan
> has no working config from the get go? Does the user just
> dpkg-reconfigure to set it up?

I decided to remove the debconf pieces and just provide a commented out base template configuration file as debconf was much hassle than it was worth. OpenVPN also doesn't provide a base configuration/debconf.

> Strongswan (and unbound / ldns) all need a team bug subscriber.
> What team will look after these in main?

Looking at OpenVPN / BIND, I would say that this is the server team's realm.

> As for unbound, I'd also be interested in an assessment of how bad bug 988513 is.

This sounds like the 'these packages are [...] highly opinionated about "correctness" over "compatability"' that Seth was referring to.

> It's just there so we can build a couple optional plugins of strongswan.

I'd rather we enabled as many plugins as possible so that people don't have to recompile the source every time we leave out a plugin they need.

> Could we split some of the strongswan plugins into their own source?

That'd be a question for upstream, but it would make the package maintenance easier.