From: Joshua G Lock <joshua.g.lock@linux.intel.com>
To: yocto@yoctoproject.org
Subject: Re: Long-term package revision maintenance
Date: Thu, 10 Mar 2016 10:04:38 +0000 [thread overview]
Message-ID: <1457604278.4090.13.camel@linux.intel.com> (raw)
In-Reply-To: <56E141B0.8060102@mlbassoc.com>
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
next prev parent reply other threads:[~2016-03-10 10:04 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-10 8:12 Long-term package revision maintenance Gary Thomas
2016-03-10 9:35 ` Joshua G Lock
2016-03-10 9:43 ` Gary Thomas
2016-03-10 10:04 ` Joshua G Lock [this message]
2016-03-10 10:09 ` Gary Thomas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1457604278.4090.13.camel@linux.intel.com \
--to=joshua.g.lock@linux.intel.com \
--cc=yocto@yoctoproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.