You should update your complete image regularly, as new versions become available, for both the very important reason @diizzy points out, as well as that the kernel and its modules (and, as I vaguely recall, busybox) can't be updated in place.
whatif the matters that both of you point out is true(that opkg upgrade may impact to the system since kernel dependency and so on),
the 'opkg upgrade ' has been made wrongly
since the upgrade module must check all that dependency.
I should say that
'opkg upgrade' should be proper method for everyone since exist for the purpose of existence.
'opkg upgrade' must check the all that dependency before proceeding process. I should tell this matter to the people who in charge of 'opkg upgrade' module... is there anyone know the contact of the person?? I'll raise the issue.
Actually, nothing is ever removed from the ROM (without re-flashing it). Even if you "delete" a package that is in the ROM, all that happens is that you "Wite-Out" the entry in /rom/ by adding a "nothing to see here" entry in the /overlay/ for every file and link in the package -- it actually takes more space
opkg upgrade is useful, in my opinion, for a package that you've installed yourself after flashing the ROM (where you are replacing one version on /overlay/ with another), as well as for patching one or two "critical" packages until a new ROM can be installed.
I see all of you's point. Right, ROM is ROM.
By the way, if the storage space is still enough to install it then I would still prefer the 'opkg upgrade' if there is no space, opkg will be failed. and if the user even can run the opkg on ssh console that (assume) they already aware of that storage space consumption(I believe! ).
Still...one thing remain issue is that...
'Does 'opkg upgrade' really not checking dependency?' which is serious actually.
Any more information about that?? And how to raise issue to improve if there isn't checking mechnism?
Most of the packages aren't dependent on the exact version of the kernel, as they call established kernel and operating system APIs/ABIs. To a great extent, most "user-land" packages/applications are isolated from kernel-level changes through dynamic linking to the libraries, in particular the standard C library. Just like you can keep running that old binary from 5 or 10 years ago on your desktop, many "high-level" packages run just fine on a newer version of the kernel.
Kernel modules and some drivers on the other hand, are often tightly tied to the exact build of the kernel.
If you think you've got an example where opkg upgrade "did the wrong thing" around dependencies, the posting here would be one good way to get some more people looking at it. A good report includes:
Okay thanks for thanks for the inform then no issue with the post.
So, this thread still fulfill that original purpose as the information to update system packages. There is nothing to worry with my recommendation(only storage space matter).
Have a good day.
Well, following your advice will brick many devices.
The storage space is the first killer for most devices, and the possible dependency issues is the second one.
Opkg is a lightweight package manager for resource limited devices, and its main purpose is to enable users to install a few additional packages to their devices. It can also be used to upgrade inidividual packages selectively, if you know what you do. But for a reason it does not contain a mass-update command. You created that feature via external script...
The idea of regularly blindly upgrading all packages with crontab is even worse as there is e.g. no earlier check for free flash space.
Just remember that Openwrt targets resource constrained devices using some 50 different hardware architectures, so functionality is reduced and everything does not work like in a x86-only major Linux distro.
I have created a little script called opkg-upgrade to deal with upgrading in a better way.
Interactive Upgrades can then be run with just:
It is available on github:
I mention some of the problems of upgrading right at the start of the readme.md file there. I agree that this should not be done on cron EVER!
I would say that not even on a regular Linux distro blind upgrades are a good idea.
There are many things that can go wrong on upgrades and since OpenWrt usually runs on devices that can be bricked, it makes even less sense to do it unattended.
Honestly, the only cases where I would upgrade are:
If using extroot on a huge USB stick
If internal Flash is 32Mb or bigger
If NOT using dev/trunk (beta)
If running on ext4 FS with plenty of space (x86 metal, VM, et. all)
Still, would never upgrade from cron.
I would also think 20 times before upgrading internal Flash (even big ones), since that would degrade it faster.
My script has the option to send an e-mail report with the available updates.
So I would recommend to add the reporting tool to cron, and then you can upgrade manually after receiving that. This makes things safer while also giving the option to revise the upgrades.