@Yvan-Gagnon can you please add [resolved] to the post title?
for anybody looking for the solution to installing blynk-library, the instructions in the blog post have been updated.
as per this other post on the subject.
In a nutshell, blynk-library can now be installed using npm.
I am also interested in installing rndis.
In the repository there are older versions of the kernel modules for the current kernel but they didn't work for me yet, some of them loaded correctly but something always fails so far. You can try to install them with - -
I also tried to compile my own firmware but since that is just lede without the onion customizations this is not really what I want to use.
Maybe the current packages where built for the firmware version 163? It seems that there where 161-163 versions available but they where very unstable. Maybe they deleted them but the compiled packages staid in their repository?
If I have more time I will try again to get the older packages from the repositories working. You can open the onion core repository in a browser to see the different versions from the packages and then search for them with ctrl+f. The installated opkg version doesn't seem to support installing different versions.
As a hint: opkg install with url did also not work for me, Wget + opkg install package.ipk did work and most modules even loaded. I got the virtual CD drive listed in dmesg after installing some kernel modules which wasn't the case before but I didn't get rndis to work.
I even tried to upgrade everything including the kernel but that resulted in more Lede stuff, the onion repositories where replaced by Lede repositories and the banner also was the Lede one (I only used omega repositories). I also got even more depency errors. The Kernel didn't seem to be upgradable since it stayed at the old version.
That's how --force-depends works - it still reports the errors it encounters, but completes installation anyway. When you run it the second time, the package is installed already according to opkg's housekeeping data, so there's nothing to do for opkg, and thus the dependencies are not checked again.
But of course, you still have a dependency mismatch in the installation, which might cause trouble when actually use the modules.
On the other hand, as long as the module in question is not using any bleeding edge kernel features, chances are good a third tier version mismatch does not matter.
Kernel dependency checking is so strict because if something does go wrong in the kernel, this might render the system unusable/unbootable up to the point that you need to do a low level debricking over ethernet. That's something you can risk (knowingly by specifying --force-depends) while experimenting, but don't want to happen otherwise. So while the strict checking is sometimes annonying, it makes a lot of sense.