Upgrading packages - Revision history

PaulEggleton: Fix versioning policy link

2014-06-05T13:24:00Z

Fix versioning policy link

← Older revision		Revision as of 13:24, 5 June 2014
Line 27:		Line 27:

	* If it is present, remove any line setting PR on upgrades (when PV changes).		* If it is present, remove any line setting PR on upgrades (when PV changes).
	* Generally we try to avoid pre-release versions; however sometimes upstream doesn't give us a choice. See [[Versioning ~~policy~~]] for how to deal with pre-release versions.		* Generally we try to avoid pre-release versions; however sometimes upstream doesn't give us a choice. See [[Versioning Policy]] for how to deal with pre-release versions.
	* If LIC_FILES_CHKSUM needs to be changed as part of the upgrade, you '''must''' explain exactly why in the commit message. It's fine if it is just a copyright year, formatting or other minor change; however if the license text has changed in more substantially than that it may be that the license is now materially different.		* If LIC_FILES_CHKSUM needs to be changed as part of the upgrade, you '''must''' explain exactly why in the commit message. It's fine if it is just a copyright year, formatting or other minor change; however if the license text has changed in more substantially than that it may be that the license is now materially different.

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

PaulEggleton: Add upgrade guidelines

2014-06-05T13:23:30Z

Add upgrade guidelines

← Older revision		Revision as of 13:23, 5 June 2014
Line 1:		Line 1:
			= General upgrading procedures =

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

Line 6:		Line 8:
	# You don't.		# You don't.

	= If you do not need to keep the last version of the package =		== If you do not need to keep the last version of the package ==

	# Use <code>git mv recipes-xyz/recipename/recipename_1.0.bb recipes-xyz/recipename/recipename_2.0.bb</code>		# Use <code>git mv recipes-xyz/recipename/recipename_1.0.bb recipes-xyz/recipename/recipename_2.0.bb</code>
Line 15:		Line 17:
	# Final step - publish your work. See '''[[How to submit a patch to OpenEmbedded]]'''		# Final step - publish your work. See '''[[How to submit a patch to OpenEmbedded]]'''

	= If you do want to keep the last version of the package =		== If you do want to keep the last version of the package ==

	Same as above, except instead of the first step:		Same as above, except instead of the first step:
Line 21:		Line 23:
	cp recipes-xyz/recipename/recipename_1.0.bb recipes-xyz/recipename/recipename_2.0.bb		cp recipes-xyz/recipename/recipename_1.0.bb recipes-xyz/recipename/recipename_2.0.bb
	git add recipes-xyz/recipename/recipename_2.0.bb		git add recipes-xyz/recipename/recipename_2.0.bb

			= Guidelines =

			* If it is present, remove any line setting PR on upgrades (when PV changes).
			* Generally we try to avoid pre-release versions; however sometimes upstream doesn't give us a choice. See [[Versioning policy]] for how to deal with pre-release versions.
			* If LIC_FILES_CHKSUM needs to be changed as part of the upgrade, you '''must''' explain exactly why in the commit message. It's fine if it is just a copyright year, formatting or other minor change; however if the license text has changed in more substantially than that it may be that the license is now materially different.

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

PaulEggleton: More formatting improvements; correct final step for current OE; add link to YP ref manual for buildhistory

2014-06-05T13:12:05Z

More formatting improvements; correct final step for current OE; add link to YP ref manual for buildhistory

← Older revision		Revision as of 13:12, 5 June 2014
Line 8:		Line 8:
	= If you do not need to keep the last version of the package =		= If 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>]~~ recipes-xyz/recipename/recipename_1.0.bb recipes-xyz/recipename/recipename_2.0.bb		# Use <code>git mv recipes-xyz/recipename/recipename_1.0.bb recipes-xyz/recipename/recipename_2.0.bb</code>
	# Make ~~<u>~~further changes</u> to recipes-xyz/recipename/recipename_2.0.bb as appropriate.		# Make further changes to <code>recipes-xyz/recipename/recipename_2.0.bb</code> as appropriate.
	# At the very minimum do a ~~<u>~~compilation test</u> "bitbake <~~basename~~>" to make sure the new package does at least fetch and compile.		# At the very minimum do a compilation test (<code>bitbake recipename</code>) to make sure the new package does at least fetch and compile.
	# Consider using buildhistory to check for changes between the versions.		# Consider using buildhistory to check for changes between the versions. See [http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#maintaining-build-output-quality Maintaining Build Output Quality] in the Yocto Project Reference Manual.
	# Inspect the output of "~~<u>~~git diff~~</u>~~ recipes-xyz/recipename/". Is this really what you want to commit?		# Inspect the output of "git diff recipes-xyz/recipename/". Is this really what you want to commit?
	# Final step~~, <u>~~publish your work~~</u>. "git commit packages/$pkg/ && git push"~~.		# Final step - publish your work. See '''[[How to submit a patch to OpenEmbedded]]'''

	= If you do want to keep the last version of the package =		= If you do want to keep the last version of the package =

PaulEggleton: Tweak formatting, update and extend a bit

2014-06-05T13:07:44Z

Tweak formatting, update and extend a bit

← Older revision		Revision as of 13:07, 5 June 2014
Line 1:		Line 1:
	Different layers have different policies for keeping versions of software around. Oe-Core for example is fairly agressive about having one, good, recent version of the software than many older versions. Other layers may have different policies.		Different layers have different policies for keeping versions of software around. OE-Core for example is fairly agressive 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:		There are two cases we need to consider:
Line 6:		Line 6:
	# You don't.		# You don't.

	= ~~You~~ do not need to keep the last version of the package =		= If 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"		# Use [http://www.kernel.org/pub/software/scm/git/docs/git-mv.html <u>git mv</u>] recipes-xyz/recipename/recipename_1.0.bb recipes-xyz/recipename/recipename_2.0.bb
	# ~~make~~ <u>further changes</u> to ~~packages~~/~~$pkg~~/~~$file_v2~~.bb as appropriate.		# Make <u>further changes</u> to recipes-xyz/recipename/recipename_2.0.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 <basename>" 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?		# Consider using buildhistory to check for changes between the versions.
			# Inspect the output of "<u>git diff</u> recipes-xyz/recipename/". Is this really what you want to commit?
	# Final step, <u>publish your work</u>. "git commit packages/$pkg/ && git 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 =		= If you do want to keep the last version of the package =

	Same as above, except instead of the first step:		Same as above, except instead of the first step:

	cp ~~packages~~/~~$pkg~~/~~$file_v1~~.bb ~~packages~~/~~$pkg~~/~~$file_v2~~.bb		cp recipes-xyz/recipename/recipename_1.0.bb recipes-xyz/recipename/recipename_2.0.bb
	git-~~add packages~~/~~$pkg~~/~~$file_v2~~.bb		git add recipes-xyz/recipename/recipename_2.0.bb

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

Rpurdie at 11:12, 7 November 2012

2012-11-07T11:12:49Z

← Older revision		Revision as of 11:12, 7 November 2012
Line 1:		Line 1:
	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.		Different layers have different policies for keeping versions of software around. Oe-Core for example is fairly agressive 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:		There are two cases we need to consider:

Rpurdie at 11:12, 7 November 2012

2012-11-07T11:12:23Z

← Older revision		Revision as of 11:12, 7 November 2012
Line 1:		Line 1:
	~~{{Outdated}}~~

	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.		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.

Rpurdie at 11:12, 7 November 2012

2012-11-07T11:12:07Z

← Older revision		Revision as of 11:12, 7 November 2012
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]]

PaulEggleton at 17:33, 3 November 2012

2012-11-03T17:33:32Z

← Older revision		Revision as of 17:33, 3 November 2012
Line 1:		Line 1:
			{{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:		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:

Eric: Undo revision 3287 by Yjytalamago (Talk)

2010-11-24T07:50:51Z

Undo revision 3287 by Yjytalamago (Talk)

← Older revision	Revision as of 07:50, 24 November 2010
(No difference)

Jhelwig at 03:10, 16 April 2010

2010-04-16T03:10:12Z

← Older revision		Revision as of 03:10, 16 April 2010
Line 1:		Line 1:
	~~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:

	~~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 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~~. Using the built-in rename function also ensures we can trace the changes for a package with "git 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.
	# 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 ~~that between~~ the first ~~and second~~ step ~~you do~~		Same as above, except instead of the first step:

	cp packages/$pkg/$~~file_v2~~.bb packages/$pkg/$~~file_v1~~.bb		cp packages/$pkg/$file_v1.bb packages/$pkg/$file_v2.bb
	git-add packages/$pkg/$~~file_v1~~.bb		git-add packages/$pkg/$file_v2.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.

	= Removing recipes =		= Removing recipes =