The package update is not a perfect solution but it is better to have it as is than to remove it.
Updated packages are also used by imagebuilder and attended sysupgrade. I normally generate a new image to apply updates because some devices cannot afford the extra installation. If we need updated packages for those cases, there is no reason to not publish them. If server resources are the problem, we should ask for help with more resources or reduce the build frequency but not stop it. Please, keep the repo packages updated. Reflashing is a delicate operation for remote devices and I need to prepare a long maintenance window (and I have dozens of remote locations). For security issues, I always evaluate if I need to reflash the device or if I can update just that package, especially if it will not affect the endusers operation. For x86 targets, I normally use much more package upgrade than reflash. Please, also keep opkg upgrade feature. I have no problem if there was an automated monthly, weekly or even daily dot release with all updates. However, a reflash is a complex operation for anyone with some extra packages and files and an extremely complex one when extroot is in use. This will consume more from our (specialist enduser) time, not a non-technical enduser (they will probably not upgrade the router by themselves anyway). The package upgrade has issues. One of them is that an update can break the system, normally those with small flashes. It would be nice if opkg could revert to the previous state when it fails (it also happens with opkg install). The attended sysupgrade service is a nice feature but it removes the ability to uninstall a package after an upgrade (and it does not work with extroot). I would prefer a solution where the extra packages were appended to the backup file or downloaded after reboot (if we could detect which packages are not required to connect to the internet). And moving a package from overlay to squashfs might introduce issues with hotplug scripts (however, that is another issue that should be fixed). Anyway, without a very frequent dot release or a repo with updates, attended sysupgrade is not a good replacement for updates. When there are pending updates, either a package or even a new image, it is not easy to know that and what was fixed. The user has no known reason for updates. For a package, repos could provide a <pkg>.changelog file, even if it was a simple raw git log. For images, it would be nice if a service like the "attended upgrade" could summarize a custom changelog for that device, with some red ink for security issues. Packages that provide kernel modules are always broken when they are updated in repo. This happens because the kernel (or its config) in the stable branch is a moving target, introducing a different kernel dependency. Buildbot always builds with the latest SDK (and kernel), which will generate kmod packages not compatible with any released images. The current workaround is to postpone those package commits until a new dot release is about to be released and manually merge them. The real solution would be to compile package mods also for each released SDK. I think the "use another downstream distribution" is the worst option by far. It simply hopes that different subgroups will independently solve the same OpenWrt issues (multiple times) and using less resources than solving them inside OpenWrt. It does not make any sense for me. It is just asking for that "other downstream distribution" to become the "de facto" new OpenWrt. I know it is not nice to maintain old releases but it is part of what a good Linux distribution should do. The reason for an OSS project is its users and reduce the number of users never helped an OSS project. I hope some day OpenWrt will be able to provide an trusted automated update system just like any decent OS and stopping to providing binary package updates for release builds just goes backwards this path. _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel