Upgrading packages: Difference between revisions

From Openembedded.org
Jump to navigation Jump to search
No edit summary
No edit summary
Line 1: Line 1:
{{Outdated}}
{{Outdated}}


Please follow these steps when upgrading a package to a more recent version. This is not to be seen as dogma, but rather as best practice. There are basically two cases we need to consider:
Different layers have different policies for keeping versions of software around. Oe-Core for example is fairly aggrressive about having one, good, recent version of the software than many older versions. Other layers may have different policies.
 
There are two cases we need to consider:


# You do want to keep the version of the bb file that is in OE now (somebody else needs this particular version)
# You do want to keep the version of the bb file that is in OE now (somebody else needs this particular version)
# You don't.
# You don't.
Make sure you add an appropriate entry in checksums.ini and run the file through contrib/source-checker/oe-checksums-sorter.py if the new version fetches new sources.


= You do not need to keep the last version of the package =
= You do not need to keep the last version of the package =


# Use "[http://www.kernel.org/pub/software/scm/git/docs/git-mv.html <u>git-mv</u>] packages/$pkg/$file_v1.bb packages/$pkg/$file_v2.bb" so that we don't accumulate unecessary cruft.
# Use "[http://www.kernel.org/pub/software/scm/git/docs/git-mv.html <u>git-mv</u>] packages/$pkg/$file_v1.bb packages/$pkg/$file_v2.bb"
# make <u>further changes</u> to packages/$pkg/$file_v2.bb as appropriate.
# make <u>further changes</u> to packages/$pkg/$file_v2.bb as appropriate.
# At the very minimum do a <u>compilation test</u> "bitbake $file" to make sure the new package does at least fetch and compile.
# At the very minimum do a <u>compilation test</u> "bitbake $file" to make sure the new package does at least fetch and compile.
# inspect the output of "<u>git diff</u> packages/$pkg/".  Is this really what you want to commit?
# inspect the output of "<u>git diff</u> packages/$pkg/".  Is this really what you want to commit?
# Final step, <u>publish your work</u>.  "git commit packages/$pkg/ && git push".  Include conf/checksums.ini in your commit, if appropriate (see above).
# Final step, <u>publish your work</u>.  "git commit packages/$pkg/ && git push".


= You do want to keep the last version of the package =
= You do want to keep the last version of the package =
Line 22: Line 22:
  cp packages/$pkg/$file_v1.bb packages/$pkg/$file_v2.bb
  cp packages/$pkg/$file_v1.bb packages/$pkg/$file_v2.bb
  git-add packages/$pkg/$file_v2.bb
  git-add packages/$pkg/$file_v2.bb
= Removing recipes =
Although preventing the accumulation of cruft in the repository is good, you should take into account that distributions may be using a certain recipe and depend upon it. Therefore, before removing a recipe from the repository, do a grep in the 'conf/distro' directory. If the version you are going to remove is being explicitly used, send the respective patch to the development mailing list for 'RFC' first.
: This is too restrictive and I think above paragraph was added to this page without a directive from the core team who should have been the one to decide.  preferred-om-2008-versions.inc looks down virtually all recipes.  In essence, the above requirement for RFC translates into "all old versions have to accumulate in HEAD or an RFC for their removal sent".  I don't think that is what we want.  I will certainly not follow that like a slave for packages that I maintain (For example, I will update libassa in a minute to 3.5.0 without keeping 3.4.2 around and wasting my time on re-libtoolizing an obsolete version of a fringe package.  Sorry). --[[User:Laibsch|Laibsch]] 22:07, 18 May 2009 (UTC)


[[Category:Policy]]
[[Category:Policy]]

Revision as of 11:12, 7 November 2012

NOTE: This page has been identified as having content that is significantly out-of-date, usually because it refers to OpenEmbedded-Classic - for new projects, you should use OpenEmbedded-Core.

See OpenEmbedded Wiki Update Project for more details.

Different layers have different policies for keeping versions of software around. Oe-Core for example is fairly aggrressive about having one, good, recent version of the software than many older versions. Other layers may have different policies.

There are two cases we need to consider:

  1. You do want to keep the version of the bb file that is in OE now (somebody else needs this particular version)
  2. You don't.

You do not need to keep the last version of the package

  1. Use "git-mv packages/$pkg/$file_v1.bb packages/$pkg/$file_v2.bb"
  2. make further changes to packages/$pkg/$file_v2.bb as appropriate.
  3. At the very minimum do a compilation test "bitbake $file" to make sure the new package does at least fetch and compile.
  4. inspect the output of "git diff packages/$pkg/". Is this really what you want to commit?
  5. Final step, publish your work. "git commit packages/$pkg/ && git push".

You do want to keep the last version of the package

Same as above, except instead of the first step: 

cp packages/$pkg/$file_v1.bb packages/$pkg/$file_v2.bb
git-add packages/$pkg/$file_v2.bb
Retrieved from "https://www.openembedded.org/w/index.php?title=Upgrading_packages&oldid=5147"