Long-term package revision maintenance
I've been running local PR servers for my builds. This works quite well, as long as I don't touch my build trees.
What's the best way to manage versions long-term? i.e. if I have a deployed system that I build today, but may not touch for a long time (years?) and I might not want to keep my build trees for that long. If I just blow away the build tree, the next time I build for that target, all of the version info will be lost. I'd like to be able to pick up where I left off.
It it safe enough to just save .../cache/prserv.sqlite3? or is there a better way? I tried the bitbake-prserv-tool export but I'm not sure it does what I want. In particular, I don't plan on saving the sstate info and will probably just expect to rebuild from scratch. When I ran the export, I see things like this:
$ grep bash PR-list.conf PRAUTO$bash-completion-2.1-r0$ppce500v2$5044c7315caa9edef95defcc20bdf74a = "1" PRAUTO_bash-completion-2.1-r0_ppce500v2 = "1" PRAUTO$bash-4.3.30-r0$ppce500v2$03b7364b0d93910fee2eddf1f2c83f4b = "1" PRAUTO_bash-4.3.30-r0_ppce500v2 = "1"
So, if I import this file into a new build tree, will it properly track that the next revision of bash should be r2 (assuming that its signature changes and r1 if it doesn't change)? Is it sufficient to export the PR list when I'm packing the project up and then import it back when I need to resume? I really want to be able to keep a package feed that I can manage over time without having to preserve the build tree that was used to create it.
Thanks for any advice
Signature · 4 lines
------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------
Quoted 9 lines · Gary Thomas
I've been running local PR servers for my builds. This works quite well, as long as I don't touch my build trees.
What's the best way to manage versions long-term? i.e. if I have a deployed system that I build today, but may not touch for a long time (years?) and I might not want to keep my build trees for that long. If I just blow away the build tree, the next time I build for that target, all of the version info will be lost. I'd like to be able to pick up where I left off.
We have a bitbake-prserv-tool script:
$ bitbake-prserv-tool Usage: bitbake-prserv-tool command Avaliable commands: export <file.conf>: export and lock down the AUTOPR values from the PR service into a file for release. import <file.conf>: import the AUTOPR values from the exported file into the PR service.
I haven't used it but it certainly reads like what you want?
Regards,
Joshua
Quoted 21 lines · Joshua G Lock
Quoted 9 lines · Gary Thomas
I've been running local PR servers for my builds. This works quite well, as long as I don't touch my build trees.
What's the best way to manage versions long-term? i.e. if I have a deployed system that I build today, but may not touch for a long time (years?) and I might not want to keep my build trees for that long. If I just blow away the build tree, the next time I build for that target, all of the version info will be lost. I'd like to be able to pick up where I left off.
We have a bitbake-prserv-tool script:
$ bitbake-prserv-tool Usage: bitbake-prserv-tool command Avaliable commands: export <file.conf>: export and lock down the AUTOPR values from the PR service into a file for release. import <file.conf>: import the AUTOPR values from the exported file into the PR service.
Quoted 2 lines
I haven't used it but it certainly reads like what you want?
Did you miss all the questions I had about it (that you cut from the reply)?
Signature · 4 lines
------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------
Quoted 23 lines · Gary Thomas
Quoted 22 lines · Joshua G Lock
Quoted 10 lines · Gary Thomas
I've been running local PR servers for my builds. This works quite well, as long as I don't touch my build trees.
What's the best way to manage versions long-term? i.e. if I have a deployed system that I build today, but may not touch for a long time (years?) and I might not want to keep my build trees for that long. If I just blow away the build tree, the next time I build for that target, all of the version info will be lost. I'd like to be able to pick up where I left off.
We have a bitbake-prserv-tool script:
$ bitbake-prserv-tool Usage: bitbake-prserv-tool command Avaliable commands: export <file.conf>: export and lock down the AUTOPR values from the PR service into a file for release. import <file.conf>: import the AUTOPR values from the exported file into the PR service.
Quoted 4 lines
Quoted 2 lines
I haven't used it but it certainly reads like what you want?
Did you miss all the questions I had about it (that you cut from the reply)?
Evidently yes, apologies — I clearly need more coffee.
Unfortunately I don't have the knowledge to answer those questions, but a quick look at the git history[1], related ticket[2] and wiki[3] makes me think it was designed to work as you hope.
If you have build trees available it should be fairly cheap to verify, I think.
This seems like a scenario we should document in the "Working With a PR Service"[4] section of the Yocto Project Development Manual so please do let us know how you get on.
Regards,
Joshua
1. http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=a05e3a57c6f567578faeb31fae89b20e22850af4
2. https://bugzilla.yoctoproject.org/show
_bug.cgi?id=1556
3. https://wiki.yoctoproject.org/wiki/PR_Service#Export_Functionality
4. http://www.yoctoproject.org/docs/2.0/dev-manual/dev-manual.html#work
ing-with-a-pr-service
Quoted 35 lines · Joshua G Lock
Quoted 23 lines · Gary Thomas
Quoted 22 lines · Joshua G Lock
Quoted 10 lines · Gary Thomas
I've been running local PR servers for my builds. This works quite well, as long as I don't touch my build trees.
What's the best way to manage versions long-term? i.e. if I have a deployed system that I build today, but may not touch for a long time (years?) and I might not want to keep my build trees for that long. If I just blow away the build tree, the next time I build for that target, all of the version info will be lost. I'd like to be able to pick up where I left off.
We have a bitbake-prserv-tool script:
$ bitbake-prserv-tool Usage: bitbake-prserv-tool command Avaliable commands: export <file.conf>: export and lock down the AUTOPR values from the PR service into a file for release. import <file.conf>: import the AUTOPR values from the exported file into the PR service.Quoted 4 lines
Quoted 2 lines
I haven't used it but it certainly reads like what you want?
Did you miss all the questions I had about it (that you cut from the reply)?
Evidently yes, apologies — I clearly need more coffee.
Unfortunately I don't have the knowledge to answer those questions, but a quick look at the git history[1], related ticket[2] and wiki[3] makes me think it was designed to work as you hope.
Quoted 6 lines
If you have build trees available it should be fairly cheap to verify, I think.
This seems like a scenario we should document in the "Working With a PR Service"[4] section of the Yocto Project Development Manual so please do let us know how you get on.
Thanks, I will give it a go soon.
Quoted 14 lines
Regards,
Joshua
1. http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=a05e3a57c6
f567578faeb31fae89b20e22850af4
2. https://bugzilla.yoctoproject.org/show
_bug.cgi?id=1556
3. https://wiki.yoctoproject.org/wiki/PR_Service#Export_Functionality
4. http://www.yoctoproject.org/docs/2.0/dev-manual/dev-manual.html#work
ing-with-a-pr-service
Signature · 4 lines
------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------