Stannieman Posted April 16 Posted April 16 Hi! I'm sorry if the answer to my question is already documented somewhere, but I couldn't find it. I am trying to figure out how to build a specific release. My understanding is that you checkout the desired tag of the armbian/build repo and just build it. However, when I do this with v24.2.1 the image that comes out is named 24.5.0-trunk. Changing the version in the VERSION file (by default set to 24.5.0-trunk) changes the name of the output image, but it is not clear to me if that affects other things than just this. So basically, now I am confused which scenario is correct: Is using the armbian/build tag the correct way to build a specific release and is the VERSION file just cosmetic? Is setting the version in the VERSION file the correct way and should any commit in armbian/build be able to generate the same image, provided the commit is new enough? A 3rd more correct way that I'm not aware of? Can anyone help me out here? Regards Stan 0 Quote
Solution Werner Posted April 17 Solution Posted April 17 8 hours ago, Stannieman said: that you checkout the desired tag of the armbian/build repo and just build it. Hi, Unfortunately this is not the case (yet). Tags are more or less just for archiving the state of the build framework at a certain point of time (usually at release). Due to its design we are not there yet to have working tags that could reproduce older images. It is our goal to have this working at some point but things are processing very slow. VERSION doesn't do anything and is pure cosmetics. 0 Quote
going Posted April 17 Posted April 17 5 часов назад, Werner сказал: VERSION doesn't do anything and is pure cosmetics. The entry in this file is used as the package version. 13 часов назад, Stannieman сказал: Changing the version in the VERSION file (by default set to 24.5.0-trunk) changes If you want the packages you have collected to be installed and then they are not updated to packages from the Armbian repository, then the version in your build should be higher than the current one for today. I.e. 24.5.1-trunk. 0 Quote
Stannieman Posted April 17 Author Posted April 17 Ok so RE the builds: That means that if you want to build an image that corresponds to one of versions listed here (https://docs.armbian.com/Release_Changelog/) you pretty much need to build on release day. Otherwise it is possible that some commits for the next version are already merged in and will be part of the build, right? What kind of work is needed for specific version builds to work? I guess the build scripts need to also checkout that version from other repos and today it just takes the latest of everything? And RE the version file: What do you mean with "If you want the packages you have collected to be installed..."? Is that for the OFFLINE_WORK=yes option so that the current online version appears older than the local build? 0 Quote
going Posted April 17 Posted April 17 54 минуты назад, Stannieman сказал: What do you mean with "If you want the packages you have collected to be installed..."? Ambiguity of the translation Unfortunately, it is not possible to build a specific version or, in other words, repeat the build. Let's assume that I'm building all the packages and installing them in a future image. I have made my custom changes in the kernel package and in two other packages. And I don't want these packages of mine to be updated when the OS is updated. In this case, I install a version larger than the latest version in the Armbian repository. Another case. I've put together three packages and just want to install them into an already running OS on the device. I'm doing the same thing with the version. That's what I meant. 0 Quote
going Posted April 17 Posted April 17 1 час назад, Stannieman сказал: OFFLINE_WORK=yes This option can only be used when you have already done the build once. The sources in the cache folder have been updated or created. By applying this parameter, the build system should not update local sources and their state should not change. In this case, it is possible to achieve repeatability of the assembly. But this is only local. It is not possible to re-build a package that exists in a remote repository. 0 Quote
Stannieman Posted April 18 Author Posted April 18 Ok that's all clear now, thanks a lot for the answers! 0 Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.