Upgrading packages: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
|||
| Line 1: | Line 1: | ||
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: | |||
# 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. | |||
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. | 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. | ||
| Line 7: | Line 8: | ||
= 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" so that we don't accumulate unecessary cruft. | ||
# 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. | ||
| Line 15: | Line 16: | ||
= You do want to keep the last version of the package = | = You do want to keep the last version of the package = | ||
Same as above, except | Same as above, except instead of the first step: | ||
cp packages/$pkg/$ | cp packages/$pkg/$file_v1.bb packages/$pkg/$file_v2.bb | ||
git-add packages/$pkg/$ | git-add packages/$pkg/$file_v2.bb | ||
= Removing recipes = | = Removing recipes = | ||
Revision as of 03:10, 16 April 2010
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:
- 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.
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
- Use "git-mv packages/$pkg/$file_v1.bb packages/$pkg/$file_v2.bb" so that we don't accumulate unecessary cruft.
- make further changes to packages/$pkg/$file_v2.bb as appropriate.
- At the very minimum do a compilation test "bitbake $file" to make sure the new package does at least fetch and compile.
- inspect the output of "git diff packages/$pkg/". Is this really what you want to commit?
- Final step, publish your work. "git commit packages/$pkg/ && git push". Include conf/checksums.ini in your commit, if appropriate (see above).
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
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). --Laibsch 22:07, 18 May 2009 (UTC)