The general update process of OpenWrt is sysupgrade: flashing a new binary image. You will not help by trying to convince people otherwise and emphasizing that it’s a bug when blindly opkg core package upgrades break existing installations with older dependencies.
OpenWrt is firmware for small resource limited embedded wireless routers. It’s not a general Linux distribution that is updated via packages.
At the same time while it’s a firmware OpenWrt offers the freedom to install current packages on existing installations. This may break things but improves flexibility and expandability.
If you like to improve OpenWrt opkg packages and take care that every new package version never breaks existing older branch installations: please implement this.
Criticism without doing anything productive and repeating the same misunderstandings does not help and is off topic in this thread.
If you like to continue debating this over and over again please start a new thread. I can repeat this as much as you like without capturing this release candidate topic thread.
There are one million ways to break your installation by doing the wrong thing when you using OpenWrt, if you would like to prevent that from happening you would end up with something similar to the OEM firmwares and event these are not able to prevent users to break the installation when they are going to perform advanced configurations.
Not being foolproof is what makes OpenWrt extremely powerful and flexible. I definitely prefer it that way.
Nice that you realized that installing new packages may install newer versions of other packages. Nice, really nice. Now you have to find solution for that logical problem and you just say "things may break just because of installing new packages, but that's OK".
That's example of bad package maintainance. Your constant "fork OpenWRT", "do not dare to criticize" hardly stimulates users to migrate to OpenWRT.
I am actually with @timur.davletshin on this, the "never upgrade packages because it breaks stuff" mantra being repeated ad-nauseam here (at least wrt. to release branches) is not helpful at all and it indeed is the product of sloppy packaging and sometimes lacking maintainers discipline and/or awareness wrt. API and ABI compatibility issues.
The various LuCI related wireless info quirks within the RC phase due to the libiwinfo update for example were an extremely unlucky upstream change. The libiwinfo library ABI was broken in the middle of the release process which lead to a number of downstream issues, mainly in the LuCI rpd plugin because it relies on naive file globbing + dlopen() to find a libiwinfo.so to load, which must not necessarily be the one it was linked against. This was an unlucky oversight and it will be fixed eventually, but it could've been avoided completely by simply not touching such a vital library between two RCs. If at all, such updates should be done with extreme scrutiny. A "let's change the datatype from uint32_t to uint64_t in the middle of a public struct"-kind of change should raise alarm bells.
Same goes for a lot of other packages, especially library ones, which often do not track the ABI at all and simply ship an unversioned .so file. Some amount of breakage is to be expected, e.g. when migrating between major versions of a package etc. But simply upgrading libiwinfo or rpcd-mod-iwinfowhile being on a release should not break things. If it does, it is a bug that must be addressed, in the worst case by reverting the offending change if it cannot be done in a forward- and backwards-compatible manner.
Unfortunately a lot of maintainers and/or contributors treat OpenWrt as a source level distribution only with little to no regard for binary packaging requirement and package lifecycle considerations.
Ideally OpenWrt would work like other Linux distros in that a simple 'apt-get update all' (opkg in this case) would put you up to date. Even FreeBSD based pfSense works this way, a simple update to latest packages no reboot needed.
However, the nature of small embedded hardware is different where we are stuck with squashfs for most of them. The sysupgrade flash method works well for that. Perhaps someday there will be a move to a proper Linux update system like other successful upstream efforts (DSA, nftables, LTS kernel, etc).
There are some solid options like the R4S that uses SD cards, or the many x86-64 devices with SSDs of course. Those will be formatted ext4 and could work better for an 'apt-get update' approach.
Sysupgrade is made a little easier if you use one of the many dual boot/dual firmware routers (my WRT32X is a good example, looks like DL-WRX36 might get it soon too), the advanced-reboot package is great.
Anyway, once you get used to the constraint what we have works well enough for now. On to rc3
I agree with @odrt and it'd be great if mods would split this discussion off into a separate topic. One point that I haven't seen mentioned here is that maybe the happy medium would be to continue to allow it but just have it prompt the user with a custom OpenWRT warning before the command gets executed? (Does it already do this? If not, is there an easy way to add such a custom warning in opkg?)
Awesome change in RC3, preview of ports on main page. (Archer C6 V3) So far it works for a few minutes, but I think it's ok Regards and thank you for your work
I only have two ports of four: "eth0" on wan and "eth1" on lan, "eth2" and "eth3" not displayed. I'm running SNAPSHOT updated maybe two hours ago.
I decided to experiment, so I moved the cable on eth1 to eth2 and the display does not change, still shows "eth1" where it seems like it should be "eth2" (yes, I flush the browser cache ctrl+shift+r in FF). I do see the change in ifconfig output, and even if I plug in a couple of machines so three ports working, then it still only shows two ports.
Do these widgets have any hotplug script to update them, or are they configured at router boot time and then remain static?
Not that it really matters, but the ports preview on the main page is not exclusive of rc3, it was already present in a more recent build of rc2 I pulled from the firmware selector. As it's likely a luci thing and any of the rcs is pulling the same code from luci.
I have the same, but I have a black background
