BKMs for Package Updating - Revision history

Dawnfoster: Blanked the page and redirected it to the correct location

2010-11-10T21:08:18Z

Blanked the page and redirected it to the correct location

← Older revision		Revision as of 21:08, 10 November 2010
Line 1:		Line 1:
	~~This page is used for capturing the Best Known Methods~~ (BKMs) ~~of package upgrading as we get reviewed and process more of the packages.~~		#REDIRECT [[Best_Known_Methods_(BKMs)_for_Package_Updating]]

	~~==Don't Retain older Versions==~~

	Unless there is a specific need (which will probably occur for GPLv2, this has also happened in the past when platforms have known bugs in the latest version) don't retain older versions of the recipe files and patches.

	~~== Use git mv to rename recipe and patches ==~~

	~~From Josh:~~
	Generally the way I perform recipe upgrades is to use git mv to rename the old file to the new version, this means that you don't have to consciously delete the old version later (win 1) and that git tracks the rename and the differences with the old file, which doesn't happen with a delete and add (win 2).

	~~The advantage of this is that you and any reviewers can more easily see what has changed with the updated version of the recipe.~~


	Nitin: Actually {git mv a b} is nothing but {mv a b; git rm a; git add b} And the file renames are detected by git automatically by looking at the file contents. Because of this git behavior, git shows some renames as renames and sometimes not. And I did not find a way to force git to understand renames. So if after "git mv" git is showing "file add & file remove", then don't get surprised, it's normal git operation.

	~~=== Reset PR to 0 (or add PR) when upgrading recipes ===~~

	~~This is a good visual reminder to bump in the future if needed.~~

	~~== For upgrades it's ok to use OE for inspiration ==~~

	~~When upgrading packages, do the git mv as above, and build if it breaks, it's OK to check the OE equivalent and grab new patch or configuration change, just don't grab the whole recipe.~~

	~~Be sure to add a credit to OE in your commit message when you do take a change like this.~~

	~~Review: [[Merging packages from OpenEmbedded]]~~

	~~== For new package grab OE version, but sanitize them ==~~

	~~Follow the recipe rules for Yocto when you take an OE recipe, be sure to clean all the OE'isms out~~

	~~Again, give credit to OE in commit messages~~

	~~Review: [[Merging packages from OpenEmbedded~~]]

	~~== Do NOT Merge .inc / .bb files ==~~

	This was a decision that slipped by me, and was not communicated well, we do not want to merge the common ".inc" files and recipe (.bb) files. This is the case even if the .bb only contains a require and a PR="r0" line. This does not mean split everything at this point, but don't merge going forward.

	~~== White Space Management ==~~


	* Most variables such as SRC_URI should use spaces.

	* Shell functions should use tabs

	* Python functions should use spaces (4 spaces per indent).

	~~== Commenting in Patches ==~~

	When you change or add patches, be sure to include attributions of where the patch came from, along with your full name and email similar to "Signed-off-by", no special tag is needed (yet?), but having your full name and email is important to track it.

	~~== New style patch application ==~~

	~~The patch and pnum parameters have been renamed to the more logical apply and striplevel. The apply parameter takes either "yes" or "no" and the striplevel parameter takes an integer (0, 1, etc).~~

	~~Both parameters are now optional with "sane" defaults.~~

	~~The apply parameter is optional for SRC_URI lines with patch or diff extensions, which will default to being applied.~~

	~~The striplevel parameter is also optional with a default striplevel of 1.~~

	~~Old style parameters (patch and pnum) will continue to work for some time but it would be useful to move to the new style syntax as people are updating other parts of their recipes.~~

	~~Therefore a patch line would be changed from:~~

	~~file://some.patch;patch=1;pnum=2~~

	~~to:~~

	~~file://some.patch;striplevel=2~~

	~~and a patch line:~~

134.134.137.73 at 18:11, 26 October 2010

2010-10-26T18:11:44Z

← Older revision		Revision as of 18:11, 26 October 2010
Line 1:		Line 1:
	This page ~~will be~~ for capturing the BKMs of package upgrading as we get reviewed and process more of the packages.		This page is used for capturing the Best Known Methods (BKMs) of package upgrading as we get reviewed and process more of the packages.

	==Don't Retain older Versions==		==Don't Retain older Versions==
Line 48:		Line 48:
	* Python functions should use spaces (4 spaces per indent).		* Python functions should use spaces (4 spaces per indent).

	== Commenting in ~~Pacthes~~ ==		== Commenting in Patches ==

	When you change or add patches, be sure to include attributions of where the patch came from, along with your full name and email similar to "Signed-off-by", no special tag is needed (yet?), but having your full name and email is important to track it.		When you change or add patches, be sure to include attributions of where the patch came from, along with your full name and email similar to "Signed-off-by", no special tag is needed (yet?), but having your full name and email is important to track it.

Scottrif at 20:15, 22 October 2010

2010-10-22T20:15:50Z

← Older revision		Revision as of 20:15, 22 October 2010
Line 51:		Line 51:

	When you change or add patches, be sure to include attributions of where the patch came from, along with your full name and email similar to "Signed-off-by", no special tag is needed (yet?), but having your full name and email is important to track it.		When you change or add patches, be sure to include attributions of where the patch came from, along with your full name and email similar to "Signed-off-by", no special tag is needed (yet?), but having your full name and email is important to track it.

			== New style patch application ==

			The patch and pnum parameters have been renamed to the more logical apply and striplevel. The apply parameter takes either "yes" or "no" and the striplevel parameter takes an integer (0, 1, etc).

			Both parameters are now optional with "sane" defaults.

			The apply parameter is optional for SRC_URI lines with patch or diff extensions, which will default to being applied.

			The striplevel parameter is also optional with a default striplevel of 1.

			Old style parameters (patch and pnum) will continue to work for some time but it would be useful to move to the new style syntax as people are updating other parts of their recipes.

			Therefore a patch line would be changed from:

			file://some.patch;patch=1;pnum=2

			to:

			file://some.patch;striplevel=2

			and a patch line:

Scottrif at 20:15, 22 October 2010

2010-10-22T20:15:03Z

← Older revision		Revision as of 20:15, 22 October 2010
Line 47:		Line 47:

	* Python functions should use spaces (4 spaces per indent).		* Python functions should use spaces (4 spaces per indent).

			== Commenting in Pacthes ==

			When you change or add patches, be sure to include attributions of where the patch came from, along with your full name and email similar to "Signed-off-by", no special tag is needed (yet?), but having your full name and email is important to track it.

Scottrif at 20:13, 22 October 2010

2010-10-22T20:13:05Z

← Older revision		Revision as of 20:13, 22 October 2010
Line 38:		Line 38:

	This was a decision that slipped by me, and was not communicated well, we do not want to merge the common ".inc" files and recipe (.bb) files. This is the case even if the .bb only contains a require and a PR="r0" line. This does not mean split everything at this point, but don't merge going forward.		This was a decision that slipped by me, and was not communicated well, we do not want to merge the common ".inc" files and recipe (.bb) files. This is the case even if the .bb only contains a require and a PR="r0" line. This does not mean split everything at this point, but don't merge going forward.

			== White Space Management ==


			* Most variables such as SRC_URI should use spaces.

			* Shell functions should use tabs

			* Python functions should use spaces (4 spaces per indent).

Scottrif at 20:12, 22 October 2010

2010-10-22T20:12:16Z

← Older revision		Revision as of 20:12, 22 October 2010
Line 34:		Line 34:

	Review: [[Merging packages from OpenEmbedded]]		Review: [[Merging packages from OpenEmbedded]]

			== Do NOT Merge .inc / .bb files ==

			This was a decision that slipped by me, and was not communicated well, we do not want to merge the common ".inc" files and recipe (.bb) files. This is the case even if the .bb only contains a require and a PR="r0" line. This does not mean split everything at this point, but don't merge going forward.

Scottrif at 20:08, 22 October 2010

2010-10-22T20:08:59Z

← Older revision		Revision as of 20:08, 22 October 2010
Line 24:		Line 24:

	Be sure to add a credit to OE in your commit message when you do take a change like this.		Be sure to add a credit to OE in your commit message when you do take a change like this.

			Review: [[Merging packages from OpenEmbedded]]

			== For new package grab OE version, but sanitize them ==

			Follow the recipe rules for Yocto when you take an OE recipe, be sure to clean all the OE'isms out

			Again, give credit to OE in commit messages

	Review: [[Merging packages from OpenEmbedded]]		Review: [[Merging packages from OpenEmbedded]]

Scottrif at 20:07, 22 October 2010

2010-10-22T20:07:57Z

← Older revision		Revision as of 20:07, 22 October 2010
Line 18:		Line 18:

	This is a good visual reminder to bump in the future if needed.		This is a good visual reminder to bump in the future if needed.

			== For upgrades it's ok to use OE for inspiration ==

			When upgrading packages, do the git mv as above, and build if it breaks, it's OK to check the OE equivalent and grab new patch or configuration change, just don't grab the whole recipe.

			Be sure to add a credit to OE in your commit message when you do take a change like this.

			Review: [[Merging packages from OpenEmbedded]]

Scottrif at 20:06, 22 October 2010

2010-10-22T20:06:46Z

← Older revision		Revision as of 20:06, 22 October 2010
Line 4:		Line 4:

	Unless there is a specific need (which will probably occur for GPLv2, this has also happened in the past when platforms have known bugs in the latest version) don't retain older versions of the recipe files and patches.		Unless there is a specific need (which will probably occur for GPLv2, this has also happened in the past when platforms have known bugs in the latest version) don't retain older versions of the recipe files and patches.

			== Use git mv to rename recipe and patches ==

			From Josh:
			Generally the way I perform recipe upgrades is to use git mv to rename the old file to the new version, this means that you don't have to consciously delete the old version later (win 1) and that git tracks the rename and the differences with the old file, which doesn't happen with a delete and add (win 2).

			The advantage of this is that you and any reviewers can more easily see what has changed with the updated version of the recipe.


			Nitin: Actually {git mv a b} is nothing but {mv a b; git rm a; git add b} And the file renames are detected by git automatically by looking at the file contents. Because of this git behavior, git shows some renames as renames and sometimes not. And I did not find a way to force git to understand renames. So if after "git mv" git is showing "file add & file remove", then don't get surprised, it's normal git operation.

			=== Reset PR to 0 (or add PR) when upgrading recipes ===

			This is a good visual reminder to bump in the future if needed.

Scottrif at 20:05, 22 October 2010

2010-10-22T20:05:15Z

← Older revision		Revision as of 20:05, 22 October 2010
Line 1:		Line 1:
	This page will be for capturing the BKMs of package upgrading as we get reviewed and process more of the packages.		This page will be for capturing the BKMs of package upgrading as we get reviewed and process more of the packages.

			==Don't Retain older Versions==

			Unless there is a specific need (which will probably occur for GPLv2, this has also happened in the past when platforms have known bugs in the latest version) don't retain older versions of the recipe files and patches.