There are 3 threads from today in the other forum regarding okpg upgrade breaking OpenWrt (1, 2, 3). And there are others in the past, of course. @jeff can attest to this!
Those of us who have more experience with OpenWrt know that it is a bad idea to use opkg upgrade (unless there is a very specific reason) as things can break. But many other users do not know -- they assume that it is just like any other linux installation and that the upgrades should work most of the time.
With that said, is there a way to safeguard opkg upgrade on OpenWrt. I'm thinking of something like the Voltaire/Spiderman warning that comes up the first time a user types sudo in many linux distros. ("Are you sure you want to run opkg upgrade? This may break your OpenWrt installation.") Or possibly require some additional argument (maybe '-force') before it will do anything. The idea is to warn the user or to make it necessary for a novice to look up (on the OpenWrt wiki/documentation/forums) why it isn't performing the upgrade (at that point, they are informed of the risks, but the tool still works).
It probably would be bad to to totally cripple or remove the functionality because there are legitimate times that this could be useful, but it seems to cause many users serious headaches.
FWIW, I am not a developer, just an enthusiastic user and contributor on the forums... so I wouldn't be the one to implement such a change. Beyond that, there may be good reasons to not mess with it -- things I wouldn't know as a non-dev type.
The referenced problems all seem to have come about by the use of manual or automated "upgrade everything" actions.
It will, unfortunately, be not only command-line use of opkg, but also people who blindly follow many of the threads here on "How I Upgrade Packages", which have, in some cases, included the suggestion of a cron job.
@jeff - good points. Ouch.... lots of threads there. This does present some challenges, for sure.
So as a thought experiment: Let's say a user was blindly following some old thread and setup a cron job or issued the commands... if an additional argument was required (my '-force' idea), wouldn't that prevent the upgrade from happening, thus saving the user from themselves? From there, they'd hopefully visit the forums/documentation to understand why it isn't doing anything and learn about the risks.
Sure, there are going to be some contributors who just create threads which include the '-force' argument without any context/warning, so the problem of blind following still exists....
but would this extra argument be, on average, a benefit or would it just add complication and get in the way?
Instruct the user how to do it correctly => Create a page in the wiki that does this job.
Plant links to this page in relevant wiki pages
Plant links to this page in forum topics regarding package upgrade
Make this page appear in the 10 first google results when searching for openwrt packages (#9 in googles query ranking for openwrt.org) openwrt install (#88) install openwrt (#123) openwrt install package (#292) openwrt upgrade openwrt upgrade packages openwrt ....addyoursearchwordcombinationhere
My only concern here is that there are plenty of users who may not look for information about the package upgrade process since they'll just assume it works like the big distros and run opkg upgrade without thinking twice about it. But, that risk aside, I do agree with @tmomas that better (surfacing of) documentation would hopefully lead the user to the appropriate information. Maybe the same documentation could be directly linked from within the QSG page under a new link about "Updating and Upgrading"
On most platforms it makes little to no sense upgrading packages as you'll just "mask" the files so in general flashing and reinstall is the best option.
Yet another thread here where the OP first blindly followed instructions to use an opkg upgrade based script and then, even after being warned not do use the script, still believed that opkg upgrade was okay (but should just be run manually). Yes, documentation will help, but is there a technical means of protecting the user from themselves that is both reasonable in the amount of effort to implement and that doesn't make it too difficult to use the opkg upgrade feature when it is actually useful and safe? I agree that documentation is an important element here, but I still think that some technical measures could help, too For example, most modern desktop OSs don't expose their critical system files by default; sudo is necessary to make changes to said files when running as a normal user, etc. -- obviously these are more complex, big distros and it is possible for a user to bypass the protections (by design), but there are good reasons for these protections.
All that said, since I'm not a software developer and not a project leader, I'm not in a position to make or direct such changes. And I also don't have the knowledge to understand the ripple effects/risks of these changes anyway... I defer to those with the experience here. And I sincerely appreciate all the work that the dev teams put into this project!!
And the previous thread about Wireguard problems (which was really caused by the opkg upgrade) showed that even with the warnings provided by multiple people, the OP still was not convinced opkg upgrade is often bad until the last major comment.
Just to add another related thread to this conversation, it appears that the upgrade from 18.06.1 > 18.06.2 failed for at least one user after using opkg upgrade. Running firstboot and then trying again fixed the issue.