OpenWrt 23.05.0-rc2 - Second Release Candidate

So ami. But it doesn't mean that I should approve bad design.

1 Like

If you go LUCI -> System -> Software and press button ->Update List then press button -> Updates .... these updates show up ! Adblock and other stuff too... not only system stuff...

but as I see, this UPDATE button, is more a dangour then usefull as you explained, people shouldnt do updates..Bravo :wink:

The package upgrades don’t „show up“ by themselves. You need to actively search for them and you decide if and when to upgrade.

The point is already understood, this may be confusing to end users who expect this to be comparable to general Linux distributions, that OpenWrt is not.

I still prefer the choice of being able to decide by myself instead of being restricted because my installation might break if I upgrade packages that I should not upgrade.

rc3 was tagged a few minutes ago...

Rc3 builds will likely be ready in 1-2 days and after that the rc3 should be officially announced if nothing bad surfaces in the build process. (Most recent 23.05-snapshot build (from practically same code base) has succeeded ok, so no surprises expected from the build process.)


Interesting. 2 examples. For some task we require replace wpad-basic-mbedtls -> wpad-mbedtls, dnsmasq -> dnsmasq-full. These recommendations are exist on wiki. We remove first package and then install the second one. After this operation we get upgraded version of the package. This fact contradicts with recommendation "Don’t upgrade packages" from your wiki link.

What do you think?


We could get upgraded packages for the case that the installed image is old enough, dependencies need to be upgraded to install the package and current package versions are newer than the version of the installed image.

Of course there are exceptions to the general rule where package upgrades make sense.

This is included in the warning recommendation:

Blindly upgrading packages (manually or via script) can lead you into all sorts of trouble.

Just because there is an updated version of a given package does not mean it should be installed or that it will function properly. Inform yourself before doing any upgrades to determine if it is safe to upgrade. Avoid upgrading core packages.

Cases could exist where package upgrades make sense. This still does not mean that the general rule should be dropped to recommend against blindly upgrading core packages.

The main challenge in upgrading already existing library packages comes from possibly breaking ABI dependencies, possibly even in the middle of the upgrade installation (if certain core packages are to be updated). That may leave the system unusable, as multiple concurrent library versions are not supported (due to the size constraints).

Switching between vanilla user-space package variants, like dnsmasq - dnsmasq-full, is more straightforward. But even there the ABI issue may arise if a newer package version requires some newer library than the currently installed one.

(Or removing dnsmasq may leave you without DNS, and you might not be able to easily download the new package etc. There are that kind of pitfalls.)

In general, upgrading is possible if you know what you are doing and if any crucial packages are included in the dependency chain. But for casual first-timers, there are dangers.

So, once you know what you want, the best is to cook up a personal sysupgrade image with all packages already included in a coherent way, and sysupgrade that.


Let me help you. If upgrade breaks your installation then it is a bug. It should not be treated as a rule. In all other cases you MUST be able to upgrade packages within one release branch without any trouble. This is how it works in all other release based distributions. This is the best practice so far to be followed.

P.S. Changelogs via separate channel is a bad, bad thing.

I believe it is the reason why they don't upgrade things freely within one release branch. This is maintainer's duty to read upstream changelogs and decide which patches can be backported and if it breaks compatibility.

1 Like

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.


Glad to see the RC3 is (almost) there.
Thanks to the developers for their hard work on it.

(trying to keep a positive and constructive discussion here)


It is a bug and MUST be treated as such. There is nothing to discuss here.

1 Like

Have you seen specs of modern routers? My 6 years old APU comes with 4 gigs of RAM.

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.

1 Like

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 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-iwinfo while 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.


That was my favourite comment in this little quarrel. Smother criticism and problem disappears. I have seen it somewhere...

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 :slight_smile:


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 :slight_smile: Regards and thank you for your work

1 Like