http://www.openembedded.org/api.php?action=feedcontributions&user=91.59.27.133&feedformat=atomOpenembedded.org - User contributions [en]2024-03-29T08:34:51ZUser contributionsMediaWiki 1.29.0http://www.openembedded.org/index.php?title=Upgrading_packages&diff=1370Upgrading packages2009-05-18T22:06:37Z<p>91.59.27.133: /* Removing recipes */</p>
<hr />
<div>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. <br />
<br />
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.<br />
<br />
= You do not need to keep the last version of the package =<br />
<br />
# 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 "git log" even across upgrades.<br />
# make <u>further changes</u> to packages/$pkg/$file_v2.bb as appropriate.<br />
# At the very minimum do a <u>compilation test</u> "bitbake $file" to make sure the new package does at least fetch and compile.<br />
# inspect the output of "<u>git diff</u> packages/$pkg/". Is this really what you want to commit?<br />
# Final step, <u>publish your work</u>. "git commit packages/$pkg/ && git push"<br />
<br />
= You do want to keep the last version of the package =<br />
<br />
Same as above, except that between the first and second step you do<br />
<br />
cp packages/$pkg/$file_v2.bb packages/$pkg/$file_v1.bb<br />
git-add packages/$pkg/$file_v1.bb<br />
<br />
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.<br />
<br />
= Removing recipes = <br />
<br />
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.<br />
<br />
: I think 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 version 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 (I will remove libassa-3.4.2 in a minute, for example, rather than wasting time on re-libtoolizing an obsolete fringe package. Sorry). --[[Special:Contributions/91.59.27.133|91.59.27.133]] 22:06, 18 May 2009 (UTC)<br />
<br />
[[Category:Policy]]</div>91.59.27.133