libwebsockets: full variant provides OpenSSL - #19701
Conversation
For some time, it is not possible to install ttyd and mosquitto-ssl at the same time, so let's solve it that libwebsockets-full provides libwebsockets-openssl. This allows to install ttyd and mosquitto at the same time. Also, we need to add conflict, because we should not have installed libwebsockets-openssl and libwebsockets-full at the same time as they provides the same files. Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com>
|
IMO the right solution is to just drop the other versions. Lol, now it looks like LWS has changed again, and mbedtls is back to being a fully supported variant. Re-looking at it again, yeah, this seems like a decent enough solution. I'd personalyl rather just drop the full version altogether and make the openssl version be full, but apparently that annoyed other people. |
|
Go for it, this won't interact with any of my packages. |
|
I've just pushed another commit please check it. If it is alright, I will merge it. |
32a920c to
ff09054
Compare
| endef | ||
|
|
||
| define Package/libwebsockets-mbedtls | ||
| $(call Package/$(PKG_NAME)/Default) |
There was a problem hiding this comment.
I am thinking if I should not split this change to its own commit
There was a problem hiding this comment.
Personally, I don't think it should be changed at all, it's just style. :)
There was a problem hiding this comment.
That's true. It should be in sync with others, but let's drop this. Unrelated to my change.
They provide the same files, but they don't conflict to each other, this means that users can install them side by side. Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com>
ff09054 to
676c5c7
Compare
|
I think you should just leave the mbedtls changes out of this altogether. They might not technically conflict, as they'll just replace each other, but they're still not the same, and you can't have them both at the same time, as they have the same lib name. |
You could, and users are doing that or suggesting it to each other by forcing it. Before my commit: First, I checked which libwebsockets I have installed, then verified with the usual way that mbedtls can not be installed, and then enforced and managed to install it. TL;DR: I installed two libwebsockets packages at the same time by forcing it based on this suggested approach https://forum.openwrt.org/t/rpi4-community-build/69998/994 and this should not happen as it might lead to some cases when you are confused, which libraries are used for the package. After my commit: TL;DR: Conflicts ensure that those packages can not be installed at the same time. |
|
yeah, if it says they're both installed, that's unhelpful. You only ever get one of them actually installed. ok, go for it. |
|
Backported to all stable OpenWrt branches. |
|
Backporting this to both 1907 and 1806 seems far out of scope, and not something I endorse at all, those have wildly different lws versions and are fully EOL. (Not least of which, I don't actually believe PROVIDES and CONFLICTS work properly in those older branches) |
|
This seems to cause recursive dependency errors in master, shown by e.g. make defconfig: Strange that this apparently already got backported also to the branches already at end-of-life status. |
|
Yeah. Someone already reported it, I'm going to fix it soon. Sorry for that!
Dne út 25. 10. 2022 17:54 uživatel Hannu Nyman ***@***.***>
napsal:
… This seems to cause recursive dependency errors in master, shown by e.g.
make defconfig:
***@***.***:/Openwrt/r7800$ make defconfig
tmp/.config-package.in:59141:error: recursive dependency detected!
tmp/.config-package.in:59141: symbol PACKAGE_libwebsockets-openssl is selected by PACKAGE_libwebsockets-mbedtls
tmp/.config-package.in:59125: symbol PACKAGE_libwebsockets-mbedtls depends on PACKAGE_libwebsockets-openssl
For a resolution refer to Documentation/kbuild/kconfig-language.rst
subsection "Kconfig recursive dependency limitations"
#
# No change to .config
#
Strange that this apparently already got backported also to the branches
already at end-of-life status.
—
Reply to this email directly, view it on GitHub
<#19701 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA7IDVCFNNQTECKR6BNV4UDWE77CRANCNFSM6AAAAAARNUGXB4>
.
You are receiving this because you modified the open/close state.Message
ID: ***@***.***>
|
The issue, which is fixed by this issue, happens in all OpenWrt versions, which I used and reported, it there. It started since OpenWrt 18.06 version and those I should wait a little bit with backporting it, though. :( Recursive dependency addresses this PR #19714 |
|
I am still strongly opposed to backporting fixes that far. It's not even remotely a security issue, which you could make a case for applying to EOL software. You're giving very mixed signals, and it's largely an abuse of your privilege level to make personally satisfying fixes like this. |
Sorry for hijacking this, but FYI I find this backports very strange as well so I'm wondering if there is something we can do to prevent this. |
|
Guys, excuse me, but why you didn't take care of it two years ago when it was reported to you - #11632 ? Nobody takes the initiative to fix it and provide users friendly way to install those packages side by side and you let users to handle it by themselves by using
If OpenWrt developers would be united first, so it meets some software standards and maintenance quality, right? You should not pinpoint fingers to others if OpenWrt developers are not doing that in the main repository. Just by doing a quick look: openwrt/openwrt@2050bc4 and I can find more, if you prefer. We can discuss, if users can wait until you release a new version when they would have those packages are not. I think many OpenWrt developers just simply don't take care of this repository and now they want to increase its quality, yes. It makes sense to help us, of course, every single hand who will help us is appreciated, but if we want to get a response from OpenWrt team members, it is very hard and almost impossible to get any reaction from them. |
|
BTW IIUC then none of the your referenced commit examples are having potential to break existing users of stable release branches, but I might be of course wrong, so any link to havoc caused by those changes would be welcome. |
|
Dude, since you hijacked this thread, where you quote something about don't add new packages or don't do major upgrades, I show you examples that it happens more often, and you did not even respond to it. I can ask the same question: "What should we do to prevent this"? The same applies to adding new devices to the stable branches, right? That's why you need to start and look at things that are happening and you can not see them when you are part of OpenWrt dev team. Yes, mistakes/bugs happen. That's why there is a race condition in Python, and build testing in GitHub Actions can not reveal this, or it will be retriggered for the failed job. It is a pity that nobody has looked at it so far, but someone will need to take a look at it for an upcoming stable release, right? Then it can be backported to OpenWrt 22.03 to fix it. Also, I can bring the opposite point of view. Are you going to look for the rest failing packages in OpenWrt 22.03? Because, like now, it seems to me like you found someone who is clearly doing wrong things in the packages repository, and you did not bother to look at the main repo or for the rest feeds, which OpenWrt is using and wants to prevent things when I need to say that you did not seem to be much interested in this repository. What I need to say and what would satisfy you in the first place is to fix the race condition, I got your point, but I can not look at it right now. I have other priorities for now. |
|
Is there any way how to change openssl for full package without uninstall everything dependend on it? Well. so try uninstall it... really do not want uninstall half system just to replace one package in order to install |
Maintainer: @karlp
Compile tested: Turris 1.1, OpenWrt 21.02.5, mpc85xx/p2020
Run tested:
Before:
After:
Description:
For some time, it is not possible to install ttyd and mosquitto-ssl at the same time, so let's solve it that libwebsockets-full provides libwebsockets-openssl. This allows to install ttyd and mosquitto at the same time.
Also, we need to add conflict, because we should not have installed libwebsockets-openssl and libwebsockets-full at the same time as they provides the same files.
Fixes: #11632