Long-term package revision maintenance

Long-term package revision maintenance

[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.

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
------------------------------------------------------------

Re: Long-term package revision maintenance

[Joshua G Lock]

On Thu, 2016-03-10 at 09:12 +0100, Gary Thomas wrote:
> 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

Re: Long-term package revision maintenance

[Gary Thomas]

On 2016-03-10 10:35, Joshua G Lock wrote:
> On Thu, 2016-03-10 at 09:12 +0100, Gary Thomas wrote:
>> 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?
>

Did you miss all the questions I had about it (that you cut from the reply)?

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: Long-term package revision maintenance

[Joshua G Lock]

On Thu, 2016-03-10 at 10:43 +0100, Gary Thomas wrote:
> On 2016-03-10 10:35, Joshua G Lock wrote:
> > 
> > On Thu, 2016-03-10 at 09:12 +0100, Gary Thomas wrote:
> > > 
> > > 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?
> > 
> 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=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

Re: Long-term package revision maintenance

[Gary Thomas]

On 2016-03-10 11:04, Joshua G Lock wrote:
> On Thu, 2016-03-10 at 10:43 +0100, Gary Thomas wrote:
>> On 2016-03-10 10:35, Joshua G Lock wrote:
>>>
>>> On Thu, 2016-03-10 at 09:12 +0100, Gary Thomas wrote:
>>>>
>>>> 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?
>>>
>> 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.

Thanks, I will give it a go soon.

>
> 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
>


-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------