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 -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ -- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
