Arch Linux

" just because not everything is needed all the time."

The issue is of a completely other league.

Unknowingly using libipsec causes problems in a lot of use cases, as well as breaks existing setups. It happens all the time on the IRC channel, because newbies don't know what they're doing. Providing a split package would *at least* not break existing setups.

I'm not sure I understand the problem, generally documentation is the way you teach people what to use and what not to use.

Is there something about this software that makes it unusually likely that people will use it when they didn't intend to?
Does it get started by default?

Split packages are only used in special cases, e.g. for software that can be built with either a gtk frontend or a Qt frontend, python modules that build both a python2 and a python3 version, kernel packages where most people don't need 40MB worth of headers on top of a 70 MB kernel...
There really needs to be a good reason to split them, and I am not sure a documentation problem qualifies.

Can you elaborate on what the problem is, and how you think splitting the package would solve that problem?

In my experience, at least some people that use strongSwan seem to be allergic to reading documentation or hit badly written blog posts. IPsec and especially IKE are a seriously complex topic that is not easy to understand even for network professionals, if they never learned it before. It's even worse for newbies. In my past experience, there have been several instances of people having trouble, because they unknowingly used libipsec and came to me for help.

By default, all packages are loaded. A specific list of plugins to be loaded (`charon.load`) can be set, but not all people do that. libipsec is loaded with a higher priority than other kernel backends. Therefore, shipping it will break at least some existing setups without need. Only a very low percentage of Arch Linux installations could need libipsec. For example installations with kernels, that have no working XFRM or pfkey kernel subsystem or containers.

Shipping libipsec in a split package will enable the latter use cases and avoid breaking existing installations.

Hmm, "things loaded by default break everything for some users" does seem like a usability problem indeed. Thanks for explaining.

" For example installations with kernels, that have no working XFRM or pfkey kernel subsystem or containers."

Do we have such kernels in our repositories? I feel uncomfortable with providing split packages only for people with self-compiled kernels. We could spin that scenario endless for every package.
And as far as I know is libipsec support experimental. Furthermore I use strongswan in an isolated systemd-nspawn container. Works fine for me.

Do you have any other specific usecase why we would need a split package of an experimental feature? At the moment I don't provide this libipsec plugin because. This should work for over 90% of the use-cases.

Therefore I would like to wait for some more votes. (except you can name a good reason for enabling libipsec support via split package)

Another use case is just people that want to use libipsec for some reason. There have been some and I was not able to convince them otherwise. Their number is in the low single digits though.