How to update packages in make process but keep the main version stable?

I am trying to use stable but custom built firmware for my router.
I used this for getting the sources
"git pull v17.01.4"
but this causes the "./scripts/feeds update -a" to get a specific old and not updated repos like this
"Updating feed 'luci' from '^d3f0685d63c1291359dc5dd089c82fa1e150e0c6'"
and this causes the make to build the older packages and after installing I have to update many packages on the device and this also uses more of the device space.
what I am doing wrong .
how can I make my firmware be the latest stable one (not snapshow, that would fix the issue but would not be stable) but get the newest package that just by updating on device from the distfeed.conf would get them?
like this repo on device
"src/gz reboot_luci"
it is for version 17.01.4 but gets updated.
I hope I stated my issue clearly

17.01.4 is a point release. Development carries on after that.

I think you should use
"git checkout lede-17.01"
without the .4 if you want to track and build from the latest stuff in the stable branch.

thank you
I will test that.
so then if I want to have the last stable build I just use "git checkout lede-17.01" and everything would be changes to the stable build?
even package repos?
for the what about next versions?
how do I figure out the "lede-17.01" part myself?

Yes, from my understanding that git command should checkout the newest stable source and feeds.

For latest stable branch you might use:

mkdir build-name
cd build-name
git clone 
git fetch --tags
git tag -l
git checkout lede-17.01

git tag -l will show all availabale branches in the repo.
Where "lede-17.01" is the current latest stable branch from which you should build stable releases.

"v17.01.4" would be the a point release. Which, as of now, is older than the main lede-17.01 branch.

Use git pull to update your local repo to the latest state of the git branch tag you have choosen before.

git tag -l shows

none of them is lede-17.01
so tag is different from branch (I think)

so does git pull get all the changes (from snapshot) but applies only the lede-17 branch for me? because I checked out that branch ,right?

sorry my git is not good. just used pull till recently.

I don't think this fully explains it.
If I build LEDE against git tag lede-17.01.4, I get kernel 4.4.92 and no updates since 10/18/2017.
If I build LEDE against git branch lede-17.01, I get kernel 4.4.111 and this branch gets some kind of dozen updates a day; not what I would expect in a stable branch.
On my LEDE router, I have 17.01.4, kernel 4.4.92, but just a few (more than zero) updates since 10/18 when 17.01.4 was tagged. For example, uci was updated on 1/8/2018.
There must be some kind of facility to keep the main system stable at 17.01.4, and only allow security or other patches through, but I can't figure out how git and the build system interact to make that happen...

17.01 branch has got about 35 commits in last 30 days, so about one update per day.;a=shortlog;h=refs/heads/lede-17.01

Additionally, there can be updates on the feeds (LuCI, packages), but

Building against the HEAD of the stable 17.01 branch is the correct way.

Thanks, that helps. I did go in and look at the rate of change on the 17.01 branch, and yes, it is what I'd expect from "stable" and much less than the master branch.

I still have one question. When I build against 17.01, kernel 4.4.111 (as of now) gets put into the squashfs. My router which has opkg pointing to the official distribution point for the 17.01.04 release and is up to date runs kernel 4.4.92, and I note that the squashfs on the opkg distribution point has not been updated since the 10/13 date that the 17.01.04 tag was set on the 17.01 branch.

So.... Are the packages built against the 17.01 tag but the core system, e.g. squashfs, frozen at the 17.01.04 tag?

What happens if there is a critical kernel fix? Does it force a rebuild of squashfs, an increment in the release number.... or am I not keeping my 17.01.04 router properly up-to-date?


17.01.4 is a static old release. It will not get updated in practice. In theory, there might be a rebuild due to some core package, but in practice there would then be a 17.01.5

You can think that 17.01 HEAD is updated whenever you build it, and 17.01.4, 17.01.3 have just been snapshots on that branch's history.

That is visible in the October 2017 history of 17.01, as both 17.01.3 and 17.01.4 were tagged then:;a=shortlog;h=3eae19acee79d40ecb151a23f1f79110995f9386;a=summary

There are two kind of packages:

  • kernel-version dependent packages. There the download will happen from the old 17.01.4 repo if you are running the 17.01.4 release, but then you only download the old 17.01.4 packages. If you are running a self-build 17.01 HEAD build, you will need to recompile possible changes by yourself, as you can't install kernel packages from another version, even if only slightly different.
  • kernel-independent packages. The download points to generic 17.01 packages repo and packages can be installed to both the 17.01.4 build and a 17.10 HEAD build.

You can pretty easily see this from the download dirs:
There are 17.01.1, 17.01.2, 17.01.3 and 17.01.4 downloads (images + kernel-dependent packages) plus the packages-17.01 (generic packages).

Thank you. This helps a lot.
So in summary, the packages are rebuilt off of the HEAD of 17.01 whenever they need to be, but the core system (including kernel and mods) is snapshot and frozen at 17.01.04.