18.06.3 how is it going? --> 18.06.4 --> 19.07 coming soon

I only recently learned that the packages for a stable release are frequently updated.
Wouldn't it be safer to leave the built packages unchanged for stable releases.
The benefit would be packages could be installed at anytime without any version conflict.

If updates are needed the user should use SDK and build it all to be consistent.

Imagebuilder should default to the official stable release built packages which remain unchanged.

The "major" issue is that there's little interest in maintaining stable releases as they tend to get dated very quickly. For example, there are already several requests (PRs and wishes) to move targets to 4.19 instead of 4.14 which from a developer point of view (if you want to stay up to date) renders the 19.07 branch somewhat obsolete and yet another point of "failure" which requires time and interest for testing which looking historically most don't have.

But until ABI versioning is fixed what is the benefit of building packages for a stable release frequently.

It would be beneficial to leave it alone and just do point release every 3 -6 months to keep the stable release consistent with all the built packages.

With the current practice, buildbot resources are wasted on frequently building packages that cannot be safely used with the release.

Safety is one of the main reasons packages are updated and recompiled AFAIK - especially for stable releases.

Your lobbying in the feeds to tell maintainers to ignore release branches does not help this cause either.


Reduce the "time to market" for package security fixes is the main motivation for doing this. Building new images/point releases whenever a fix to a non-builtin package is required does not scale.

1 Like

I understand the need to keep packages up to date. I haven't had any issues installing packages but with all these warnings it is seems like something to be concerned about every time you install a package.

1 Like

Perhaps even a quarterly release[1], except in cases of critical security updates.

Once a quarter, a new "full build" -- even when there are not changes in the OpenWrt core.

So that nobody misinterprets this -- I am not asking for quarterly updates of the OpenWrt core here. You would get whatever the latest core release was, but with refreshed, self-consistent packages "good through" the predictable end of the quarter (always March, June, September, December, for example).

This way people who are looking for package upgrades get them on a reasonable cadence and those that are looking to be on the bleeding edge can work with master and snapshots.

[1] Last I checked, FreeBSD installs their quarterly package update repo as default. Things really don't change all that quickly, in general.



this is something I dont understand.
if it causes problems why at all update packages on a device that is supposed to be always on.
and if it is security-wise, then why not security packages that I have get updated?
I have gotten nano (text editor) updates on stable repo, but not Tor onion package.
even though tor is way more needed for a secure net, it is still on the same version that was shiped with the stable first release.

maybe seperate the repos into more repos(based on security and stability) .
for example why tor is in the same repo as rtorrent and why they never get updates (personal use so I remember these two).

and installing from snapshot actually causes ABI issues(I think that is what it talks about when it needs a newer library).

I used to create image from git so this was not an issue,but I got too many compile problems to do that more.

right now the only updates I get is Luci updates which I dont think are that critical( correct me if I am wrong) and I think they get updated from git because they are for web interface and losing that is not suppose to be that bad?

I am really confused by openwrt update policy.

Never had build problems myself after the initial setup, but did you try this? You do not need to build anything and it takes less than 10 minutes to get a full image with all the latest packages.

you misunderstood me.
the imagebuilder (link you provided) get the same packages as the the repo,so the "latest packages" are the same as the repo.
so using that wont change anything for my situation for tor and rtorrent and so on.

this "problem" wont be easy fixed because openwrt developers need to recognize as a problem, and as you can see from this post alone many people don't even want the update to happen for any thing, let alone peasant requested packages like mine.

if it was a way to decouple these non-core packages from main packages (very low chance) this issue would have been fixed.

I see, so you are saying that beyond the core packages everything else if way behind. Well, I guess the response to this will be that it is run by volunteers and if one needs those non-core packages, they can port them. Which makes sense to some degree: there is a limit to what you can get for free.

Like any distro, want stable, use “stable”. Want the latest, use “unstable” but be prepared to resolve your problems on your own. Debian is still on Linux 4.9 for stable, as just one example.

That OpenWrt still tries to support 4/32 devices and most devices are flash-based with limited lifespans and resources further complicates things. You can burn out NOR flash in a few years with frequent updates.

1 Like

maybe if we had a RAM installtion ? :))
the packges updates would be installed to RAM by after startup and then later every month or so to main flash.
I say this because I have 512MB ram :slight_smile:
sorry for you peasants.

Calm down, where did I tell someone to ignore the release brances? If you want to prove me wrong that there's little interest/activity overall feel free to do so. Most targets are already getting bumped to 4.19 just days after branching and that is done by core team so there's clearly a major interest in being more in sync with upstream for example.

The major issue is that on most devices you'll likely run out of space quickly as deleting old files doesn't free space which may render your device unbootable and that easily reverting a change is more or less not possible at all.

Regarding which packages gets updated or not is exactly what I'm trying to say, it's all about time and effort (irregardless of its main or packages repo). There's no "stable team", it's on induvidual bases. Jumping between OS versions is quite painful, takes time and effort not to mention that you might not want to do more testing than needed on your router etc especially if you only have one.

The "better" solution (depending on how you look at it I guess) is to simply use sysupgrade with a firmware containing updated packages, kernel etc.

I personally think that it would suit OpenWrt better given the overall contribution model/time/interest/effort but that's not for me to decide.

IMHO it would be nice if the trunk/master snapshots would come with luci (heck, even one snapshot per month with luci might be enough) as I believe master to be stable enough (most of the times :wink: ) to guide more users from stable to master, if this does not require too much of a hassle. Sure real experts will use UCI directly and/or edit config files, but casual users like myself really appreciate having a GUI available that makes many configurations easier (and having a GUI does not rule out manual edits).

But all in all, I believe that Jeff's idea of a quarterly rebuild of the stable releases to include updated packets seems like a helpful improvement...

1 Like

the quarterly update needs to include real updates packages not just security updates.
like tor and rtorrent that I mentioned.
otherwise it is just like right now.

I tend to disagree, feature updates IMHO carry a far greater risk of introducing bugs than pure updates as of security concerns (by virtue of relative numbers alone). And that is what "stable" promises IMHO. But all of this is moot, as I am not volunteering to do any of this myself (not qualified, and not willing to spend the time to learn how to do this).


If it is stability issue , maybe the way is to include a less stable more uptodate repo (not unstable, just new) that include updates like what I suggested, as in software that are not essential but have everyday use like torrent and other web servers other than uhttpd and so on.
this way there is an stable one and fresh one that in not snapshot but allows for more uptodate packages.

but I think this is too much work for this project right now.
so I guess the answer to my proposal would be to use snapshot.