It is not size what should concern you. But approach itself. It uses regular kernel, regular updates, regular linux tools. Yep, they maybe optimized for size, split into numerous packages, but it is far from true firmwares writen in hardware specific environment, delivered in one blob.
It violates principle of noncontradiction. But in practice we do it all the time. People (even technical) love to design things which are "broken" from very beginning. Providing updates via one channel and delivering information about changes in another one is one of numerous technical examples.
Size does not âconcernâ me. There is just no general popular Linux distribution that offers ready to install flash images for a working wireless router setup on my 16 MB flash and 128 MiB memory router example from a 2023 release. No concern, itâs just a lot different software concept.
You talk bad about OpenWrt design decisions while still donât show understanding of basic limitations of the environment:
I am still waiting for explainations on this statement.
1 Like
It is the same. Compiling package without unicode on internationalization support doesn't make it firmware. The way openwrt treats updates is identical to regular distributions. They are delivered in packages. Can you show me firwares with package managers? I'd love to see package manager for nvidia firmware 
Please fork OpenWrt with only sysupgrade images and no easy to use access to have opkg package upgrades.
This would then mean offering one complete frozen binary stable package repository that will not get updates for each and every release and each and every snapshot.
But as often, criticism is more easy than providing solutions for complex environments that work in reality and donât annoy enough other users to leave the project.
3 Likes
I aready answered. Not going to turn it into discussion about French philosophers.
Stop it. OpenWRT is an optimized (for specific task) Linux distribution.
Yes letâs fight over definition of words. Itâs just too boring and not just enough off topic here.
Yes, stop criticizing design decisions you have no idea about why they were being made.
I am grateful that other people here provide me this fine piece of software for free. And I also get the freedom of choice of being able to do opkg upgrade for the price of being able to break my installation if I donât follow the warning of leaving core packages intact.
Bet you put your money on people like Zuch in fights.
Lack of changelogs is a bad, bad design decision. Nothing to discuss.
2 Likes
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 
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...
- https://git.openwrt.org/?p=openwrt/openwrt.git;a=shortlog;h=94cd25cb69805ec9b3ecd5a86ab39196c51e5a2e
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.)
8 Likes
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?
2 Likes
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.
2 Likes
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