Difference between revisions of "Upgrading packages"

From Openembedded.org
Jump to: navigation, search
m
Line 1: Line 1:
 
   
 
   
Do you know about the powers of [http://monotone.ca/docs/Workspace.html#index-mtn-_005b_002d_002dbookkeep_002donly_005d-rename-_0040var_007bsrc_007d-_0040var_007bdst_007d-22 <u>mtn mv</u>]?  If you are upgrading a package you really should.   
+
Do you know about the powers of [http://www.kernel.org/pub/software/scm/git/docs/git-mv.html <u>git-mv</u>]?  If you are upgrading a package you really should.   
  
 
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; a) you do want to keep the version of the bb file that is in OE now (somebody else needs this particular version) or b) you don't.
 
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; a) you do want to keep the version of the bb file that is in OE now (somebody else needs this particular version) or b) you don't.
Line 6: Line 6:
 
= 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://monotone.ca/docs/Workspace.html#index-mtn-_005b_002d_002dbookkeep_002donly_005d-rename-_0040var_007bsrc_007d-_0040var_007bdst_007d-22 <u>mtn mv</u>] packages/$pkg/$file_v1.bb packages/$pkg/$file_v2.bb" so that we don't accumulate unecessary cruft.  Using the [http://monotone.ca/docs/Workspace.html#index-mtn-_005b_002d_002dbookkeep_002donly_005d-rename-_0040var_007bsrc_007d-_0040var_007bdst_007d-22 monotone built-in rename function] also ensures we can trace the changes for a package with "mtn log" even across upgrades.
+
# 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.  Using the built-in rename function also ensures we can trace the changes for a package with "mtn log" even across upgrades.
# 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>mtn diff</u> packages/$pkg/|less".  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>.  "mtn commit packages/$pkg/ && mtn pull && mtn merge && mtn push"
+
# 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 17: Line 17:
  
 
  cp packages/$pkg/$file_v2.bb packages/$pkg/$file_v1.bb
 
  cp packages/$pkg/$file_v2.bb packages/$pkg/$file_v1.bb
  mtn add packages/$pkg/$file_v1.bb
+
  git-add packages/$pkg/$file_v1.bb
  
Now, you may ask "Why rename the file first and then copy it back?"  Good question!  With using "mtn mv" to rename and then copying back we keep the "mtn log"-history forever.  Just "cp $a $b;mtn add $b" means we have a truncated history once $a gets removed.
+
Now, you may ask "Why rename the file first and then copy it back?"  Good question!  With using "git mv" to rename and then copying back we keep the "git log"-history forever.  Just "cp $a $b;git add $b" means we have a truncated history once $a gets removed.
  
 
[[Category:Policy]]
 
[[Category:Policy]]

Revision as of 05:20, 11 February 2009

Do you know about the powers of git-mv? If you are upgrading a package you really should.

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; a) you do want to keep the version of the bb file that is in OE now (somebody else needs this particular version) or b) 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" so that we don't accumulate unecessary cruft. Using the built-in rename function also ensures we can trace the changes for a package with "mtn log" even across upgrades.
  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 that between the first and second step you do

cp packages/$pkg/$file_v2.bb packages/$pkg/$file_v1.bb
git-add packages/$pkg/$file_v1.bb

Now, you may ask "Why rename the file first and then copy it back?" Good question! With using "git mv" to rename and then copying back we keep the "git log"-history forever. Just "cp $a $b;git add $b" means we have a truncated history once $a gets removed.