Since, for hardware limitations and too keep the firmware size reasonable, it's not possible to have proper linux-like package management, would it be feasible to handle that on the server?
I understand that this, if at all possible, may involve radical development changes, would require user consent, and will incur increased server bandwidth and CPU power that I am not sure if the project can afford. So it might not be an idea for the near future, but I wanted to bring it for long-term consideration.
Another related idea would be to push (or pull) notifications of critical security updates.
This approach falls flat, if you'd ever need to install anything offline, e.g. if you need to install additional packages to get online in the first place. While this might not be the most common usage scenario, it's still something to keep in mind. It also adds serious complications for building OpenWrt from source, as you'd somehow provide those packages via a (local-) server as well.
SUN introduced something like this for Solaris called IPS, I don't really think this has ever been seen as a good move.
I was mostly thinking of package upgrading. I started the post as a reply to the topic linked in the first post, so it was probably clear the, but I guess I should have explicity explained the angle when I made it a new topic.
So to clarify, I am suggesting something like how PCs update the OS, except that the heavy lifting will be fine by yummy server.
I realize that, but is there really a difference between installing a package (that includes inside the buildroot, while generating firmware images from source or using the imagebuilder) or upgrading it on deployed systems?
Even if there were a difference, should there be? Using two different facilities to do essentially the same thing, which both have to follow the same guidelines to be successful, inevitably ends up in a mess - as you now have two moving parts with their own share of bugs to care about.
I think parts of this idea could be interesting to implement... just brainstorming here:
what if there was a update notification/advisory feature like those seen on a mobile phone (iOS or Android). In this context, maybe it would pull information from a server. If thee were any updates/advisories of note, there would a display upon login via LuCI (maybe similar to the way LuCI warns "No password set!") or ssh (just below the banner).
The messages could be simple. For example:
A maintenance update OpenWrt 19.07.2 is available for your device (current version: 19.07.1)
A major upgrade is available for your device: OpenWrt 19.07.2 is available now. (current version: 18.06.4)
A security advisory has been posted. Please visit this page: < linked > for details. Package upgrades recommended for the following currently installed packages < package 1>, <package 2>, etc.
What I'm suggesting is an additional option for checking. When you use list-upgradable it gives you a list of what packages can be upgraded. But wouldn't it be good to know what packages should be upgraded? So it's an option that doesn't have to be used, and therefor wouldn't disturb the regular workflow if not used, or if the user builds from source (though, in the latter, I don't see why the user can't have the option to actually provide the package before building or have a list of the packages that should be safe to upgrade after flashing. They can also ignore that option completely.
suggested this in the past... it's a great idea... also said;
opt in -> user must click [enablesecuritymsgs] [enablenewstablemsgs]
shows as pop up in luci under top bar ( dismiss able )
at most simplest shows a link to openwrt official page with instructions
while something like a "one click > opkg upgrade pkgwithbug" is pretty simple / handy. i'd personally err on the side of not allowing this in the medium term... automation introduces potential vulnerabilities... and takes the risk/responsibility away from the user and places it onto the developer.
i'm particulary "anti-chatter"... so I believe such a feature should fire off once in a while ( configurable ) and not be overly chatty. ( pull... not push )
( maybe aparcar can add some json->rss info per release so this can be build on top of / alongside the attended-sysupgrade efforts )
It would be cool to have a "prepare for offline installation" download which prepares a tar file of the package and all its dependency ipks and perhaps a script to install them in the proper order so that opkg does not choke.
This could maybe part of the Image Builder?
Using for example a 4G modem or WPA-Enterprise network it's necessary to install packages to get the router back connected to the Internet after an upgrade. That often leads to needing to change configurations and/or physical connections to get online temporarily once just to run opkg.
For that scenario, you can use the image builder, and include as many extra packages as you need. Everything will be installed and ready after the upgrade.