[RFC] Stop providing binary package updates for release builds?

[Luiz Angelo Daros de Luca]

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.