strongswan: Add dependency to virtual package strongswan-mod-socket #16263

Thermi · 2021-08-01T01:36:21Z

Required to model the dependency of the charon daemon onto one of the two socket abstractions
Otherwise none will be installed and the daemon is not usable

Closes #16261

Signed-off-by: Noel Kuntze noel.kuntze@thermi.consulting

Maintainer: me / @pprindeville
Compile tested: x86_64, trunk
Run tested: Not yet

Description:

dangowrt

Please don't add the -virt suffix, we don't do that anywhere for PROVIDES and it will confuse people. Rather just let both of them provide strongswan-mod-socket and then depend on that.

dangowrt

The patch itself looks good. Please change the commit description to no longer mention -virt suffix.

pprindeville

Couple of questions...

pprindeville · 2021-08-03T21:31:12Z

net/strongswan/Makefile

+    $$(call Package/strongswan/Default)
+    TITLE:= StrongSwan $(2) plugin
+    DEPENDS:= strongswan $(3)
+    PROVIDES:= strongswan-mod-socket


Is this the big difference? This line here?

pprindeville · 2021-08-03T21:32:12Z

net/strongswan/Makefile

+    PROVIDES:= strongswan-mod-socket
+  endef
+
+  define Package/strongswan-mod-$(1)/install


You can't chain to the one below? These look identical...

How? The defines have defined ends, declared by endef.
If I were to chain it by starting the define for the BuildPluginModSocketVirt just before the one for BuildPlugin without terminating it beforehand (instead, afterwards), any call to BuildPlugin would declare a version of BuildPlugin where $(1), $(2), and $(3) are filled in with the particular values of BuildPluginModSocketVirt.

That's not good. It'd at best throw an error.

If we unnested, and had them both BuildPlugin*'s invoke the common version?

I tried that, but it's one more level of nesting and I couldn't make it work.

@jow- @nbd168 @dangowrt Can you guys help out with this problem? Shed any insight?

Merged both PR's as #16367

When I did that, make complained all the other calls to the function didn't have a fourth argument.

I think we can solve that without adding the fourth argument to all calls, by adding a wrapper function. Rename BuildPlugin to BuildPluginProvides, and add:

define BuildPlugin $(call BuildPluginProvides,$1,$2,$3,) endef

See PR #16367.

Any consensus?

I don't like the macro name BuildPluginModSocketVirt because it's more specific than the real essence of the macro...

This a virtual package that is satisfied by either strongswan-mod-socket-default or strongswan-mod-socket-dynamic, and is required by the charon daemon. When neither of these packages is installed, charon will not function. Closes openwrt#16261, openwrt#16263 and openwrt#16367. Signed-off-by: Noel Kuntze <noel.kuntze@thermi.consulting> Signed-off-by: Philip Prindeville <philipp@redfish-solutions.com> Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>

neheb · 2021-11-12T19:07:35Z

Needs a rebase.

This a virtual package that is satisfied by either strongswan-mod-socket-default or strongswan-mod-socket-dynamic, and is required by the charon daemon. When neither of these packages is installed, charon will not function. Closes openwrt#16261, openwrt#16263 and openwrt#16367. Signed-off-by: Noel Kuntze <noel.kuntze@thermi.consulting> Signed-off-by: Philip Prindeville <philipp@redfish-solutions.com> Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>

Thermi · 2022-02-07T05:00:42Z

Builds for me.

pprindeville · 2022-05-02T18:55:25Z

Needs a rebase.

Thermi · 2022-05-17T21:41:55Z

Builds and constructs the right dependencies here. strongswan-full and -minimal (metapackages) depend on socket-default, but strongswan-charon depends on strongswan-mod-socket, which is a virtual package provided by -socket-default and -socket-dynamic. So if somebody wants to uninstall -socket-default but has socket-default and -socket-dynamic, dependencies of strongswan-full and -minimal will not be satisfied anymore. If the user uninstalls them then the only dependencies on strongswan packges that are from an explicitly installed packages are from -mod-socket-dynamic which requires strongswan and libc. strongswan only packages libstrongswan. So in total if somebody switches to -socket-dynamic, removes -socket-default, and removes all unrequired packages, they will have an incomplete and unusable installation of strongwan. We could fix that by making -full and -minimal depend on -mod-socket. So it's a dependency on the virtual package.

@pprindeville thoughts?

Thermi · 2022-05-23T21:55:03Z

All the other expressions in the file have exactly one plus. Do you know better in that regard? It still throws syntax errors when building.

Required to model the dependency of the charon daemon onto one of the two socket abstractions Otherwise none will be installed and the daemon is not usable Closes openwrt#16261 Signed-off-by: Noel Kuntze <noel.kuntze@thermi.consulting>

Closes openwrt#16261 Signed-off-by: Noel Kuntze <noel.kuntze@thermi.consulting>

…t dependency providers

This a virtual package that is satisfied by either strongswan-mod-socket-default or strongswan-mod-socket-dynamic, and is required by the charon daemon. When neither of these packages is installed, charon will not function. Closes openwrt#16261, openwrt#16263 and openwrt#16367. Signed-off-by: Noel Kuntze <noel.kuntze@thermi.consulting> Signed-off-by: Philip Prindeville <philipp@redfish-solutions.com> Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>

pprindeville · 2023-04-07T18:04:03Z

Is this still open?

dangowrt requested changes Aug 1, 2021

View reviewed changes

Thermi force-pushed the strongswan-mod-socket-dep branch from 7bbb212 to 5af42d5 Compare August 1, 2021 17:51

Thermi requested a review from dangowrt August 1, 2021 20:58

Thermi changed the title ~~strongswan: Add dependency to virtual package strongswan-mod-socket-virt~~ strongswan: Add dependency to virtual package strongswan-mod-socket Aug 1, 2021

dangowrt requested changes Aug 3, 2021

View reviewed changes

Thermi force-pushed the strongswan-mod-socket-dep branch 2 times, most recently from 355976b to 4c79aed Compare August 3, 2021 18:54

Thermi requested a review from dangowrt August 3, 2021 19:01

dangowrt approved these changes Aug 3, 2021

View reviewed changes

dangowrt added the dependencies Pull requests that update a dependency file label Aug 3, 2021

pprindeville requested changes Aug 3, 2021

View reviewed changes

pprindeville requested a review from stintel August 11, 2021 06:44

Thermi force-pushed the strongswan-mod-socket-dep branch from 4c79aed to cab3024 Compare May 15, 2022 21:52

Thermi added 4 commits August 10, 2022 23:58

strongswan: use normal dependencies instead

2bfdf22

Closes openwrt#16261 Signed-off-by: Noel Kuntze <noel.kuntze@thermi.consulting>

strongswan: fix syntax

2616270

Closes openwrt#16261 Signed-off-by: Noel Kuntze <noel.kuntze@thermi.consulting>

strongswan: use same syntax as with other packages that have differen…

65c1184

…t dependency providers

Thermi force-pushed the strongswan-mod-socket-dep branch from 71bf09a to 65c1184 Compare August 10, 2022 22:39

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

strongswan: Add dependency to virtual package strongswan-mod-socket #16263

strongswan: Add dependency to virtual package strongswan-mod-socket #16263

Thermi commented Aug 1, 2021

dangowrt left a comment

dangowrt left a comment

pprindeville left a comment

pprindeville Aug 3, 2021

Thermi Aug 3, 2021

pprindeville Aug 3, 2021

Thermi Aug 3, 2021

pprindeville Aug 4, 2021

Thermi Aug 4, 2021

pprindeville Aug 5, 2021

pprindeville Aug 15, 2021

Thermi Aug 15, 2021

stintel Aug 15, 2021

pprindeville Feb 7, 2022

pprindeville Apr 25, 2022

neheb commented Nov 12, 2021

Thermi commented Feb 7, 2022

pprindeville commented May 2, 2022

Thermi commented May 17, 2022 •

edited

Thermi commented May 23, 2022

pprindeville commented Apr 7, 2023

strongswan: Add dependency to virtual package strongswan-mod-socket #16263

Are you sure you want to change the base?

strongswan: Add dependency to virtual package strongswan-mod-socket #16263

Conversation

Thermi commented Aug 1, 2021

dangowrt left a comment

Choose a reason for hiding this comment

dangowrt left a comment

Choose a reason for hiding this comment

pprindeville left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

neheb commented Nov 12, 2021

Thermi commented Feb 7, 2022

pprindeville commented May 2, 2022

Thermi commented May 17, 2022 • edited

Thermi commented May 23, 2022

pprindeville commented Apr 7, 2023

Thermi commented May 17, 2022 •

edited