I have something to say about the difference between the official version of OpenWrt and the Lean version

This topic comes from a project called Lean's OpenWRT that I found on the GitHub Chinese board
Their ecology in terms of applications is really much better than the official version of OpenWRT, and there are many more luci-apps than the official version.
This is Lean's OpenWRT LuCI Repo
The question I've always been curious about is why your officials don't look at this branch of the Repo
You guys can recall LEDE and merge it into your mainline repo, why can't you also merge Lean's OpenWRT into your mainline repo and test it?
My hope is that, since they are all OpenWRT, there will be no distinction between the Lean version and the LEDE version.
Because users who use it will have headaches saying why each version is very different, why the number of software in the official version is not as good as the Lean version.
More simply put, it doesn't matter who released it or who compiled it, as long as it doesn't affect subsequent software and firmware updates, it's enough

People have to volunteer to be the maintainers of all these new packages.

That's usually what lack of maintenance would affect.

TBH, I'd personally never heard of 'em before.

Can you give an example of said packages?

1 Like

The maintainers of the fork are free to create pull requests to the official OpenWRT repo to have their changes/packages reviewed and incorporated into the official release. The onus is very much on them to add to the official repo, rather than the other way round.

4 Likes

For example, in the OpenWRT device I'm using, there is a package called attendedsysupgrade
It says that the package files do not exist in the opkg server, so it cannot update them.

Unsupported package(s): luci-app-diskman, luci-app-mosdns, luci-i18n-mosdns-zh-cn, luci-app-argon-config, v2dat, luci-app-openclash, luci-theme-argon, luci-app-vlmcsd, luci-i18n-argon-config-zh-cn, vlmcsd, mosdns, ddns-scripts_aliyun, luci-app-fileassistant

diskman is a hard drive partitioning assistant
MosDNS is the better DNS resolution server
argon-config is the configuration assistant for the topic argon
openclash is based on the clash program and adds some additional features suitable for router use
vlmcsd is the KMS activation server for Microsoft Windows and Office
fileassistant is a file manager

These are the packages that I can use with OpenWRT 22.03.3 - r20028-43d71ad93e

There are some packages that are not available in the firmware version I'm using, or that are not on the shelf and not used by myself
For example

luci-app-openvpn-server (Unable to install)
[luci-app-access-control](https://github.com/Aslin-Ameng/luci-app-access-control)
[luci-app-oaf](https://github.com/destan19/OpenAppFilter)
luci-app-flowoffload
and someting
1 Like

You are also right, but I would also like to say that you can look at this repository a little and try to introduce some new procedures, unification and generalization
Because this fork repo is really excellent
Links to their related repo
Firmware
LuCI
Packages

That's not how it works. Everyone is free to contribute code to the OpenWRT project if they want, but it's for them to do that. You really should be speaking to the maintainers of the other project/packages and finding out why they're not contributing their code to OpenWRT.

3 Likes

I did try to ask a question in that fork repo discussion forum, but strangely, no one answered

I seem to remember what happened, because lean made a big change, lean's luci-app development language added support for lua language, and then your official repo only support js language

Check this out

He said to shelf to the official software repository need to reuse js language development, he currently does not have this plan

My personal opinion is that the restrictions on the development language should be released, even if the lua language is supported, the original author of the package will personally upload the source code, no need for me to say over here

What @krazeh and @lleachii is correct in that the maintainers of this Lean LEDE firmware would need to be willing to contribute to the official OpenWrt project.

Beyond those statements, I see two potentially major blockers:

  • The Lean LEDE project appears to be almost entirely written in Chinese. I'm pretty sure that someone would have to translate all of the documentation (including comments in the source code) and operational (i.e. user-facing) language into English fist (and ideally prepared for additional internationalization). This is, of course, achievable, but requires work.

  • It appears that the code itself is based on a fork from the LEDE project (circa 2017), and if the screenshots on this page are accurate, the kernel (4.19) is very, very old and obsolete. The maintainers of this fork would need to update their code to operate with the latest OpenWrt kernel (5.10). This would likely represent too much work to be worth it, but it could be explored if the maintainers are interested in contributing their code to OpenWrt.

3 Likes

@coolsnowwolf :point_left:

From that link.

[Since the creator has an official account, moved to ] Community Build.

1 Like