On 6/10/14, 12:31 PM, Marlon Smith wrote:
Hi everyone,
We've decided to use Yocto in our company's product! And I have a question:
Since Yocto is updated pretty frequently, at some point we'll need to freeze
everything and keep a permanent copy so that we can make small changes/bug fixes
without having to worry about anything being changed outside of our control. My
current theory is that we'll do a bitbake -c fetchall, then zip up the entire
Yocto directory and save it somewhere so we'll always have a static copy. We'll
This is really the first step. Take you Yocto Project sources, and related
downloads and store them for retrieval later. You can use the:
BB_NO_NETWORK = "1"
to ensure that the system will use your local copy and not attempt to go to the
network for downloads.
place our application and custom bsp layer under a separate Git repository, and
then to do a build we'll just combine everything together and run bitbake on the
whole thing.
This pretty much is the standard way to do it. If your BSP is based off of
another git tree, you can enable networking just for that one item if necessary.
Is there a better or recommended way of doing this?
I think you have the basics down. When it comes to upgrading and bug fixing,
this is where doing very management resources come into play.
One way to do it is just track the Yocto Project until your product release.
This way you get all of the latest fixes for the branch you choose.
Another mechanism (what I'd recommend for after product release, but some do it
during development) is to watch the changes from your starting location, to the
current state of development (either in the branch, or even master). Using this
information, you can determine if any of the items are fixes that you believe
your product will require. Use the git 'cherry-pick' option to pull down only
the fixes you are interested in. This dramatically slows the rate-of-change of
your local tree.
One thing to keep in mind, you will -always- end up with some local fix that
does not exist upstream. You should limit these as much as possible. For a
single project, it's not all that painful to carry and support your changes, but
when you start working on the next product, it's nice to be able to start with a
newer version of the Yocto Project. If you have a lot of local changes that
have not gone back to the community, you'll then have to abandon them -- or
carry them forward. This can be time consuming, and the usual reaction is to
stick with the older version to avoid this additional work.
You should always budget the time to get the fixes ready and send them back to
the community, it will save you (and others) time when getting ready for the
next project.
Thanks again, and I'm excited to start working with Yocto!
Marlon
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
