|
|
| Line 1: |
Line 1: |
| − | = Version policy for OE recipes =
| + | This page has moved to the [https://docs.yoctoproject.org/dev/contributor-guide/recipe-style-guide.html#version-policy Yocto Documentation Contributors Guide] |
| − | There is general confusion about what a correct PV string should look like. This page attempts to define a standard for packages in OpenEmbedded to follow. Whilst not mandatory, it is strongly recommended.
| |
| − |
| |
| − | OE's versioning policy aims to follow that from [http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version Debian] (and is hence compatible with opkg). One key phrase to note is "The lexical comparison is a comparison of ASCII values modified so that all the letters sort earlier than all the non-letters." This means characters like + and - have a higher priority than alphanumeric characters.
| |
| − | If in doubt, experiment with the opkg-compare-versions program from opkg-utils.
| |
| − | | |
| − | == Hyphens ==
| |
| − |
| |
| − | Our current policy is:
| |
| − | | |
| − | * PN may contain hyphens
| |
| − | * PV should avoid containing hyphens
| |
| − | * PR '''must not''' contain hyphens
| |
| − | | |
| − | It is a common misconception that hyphens are not allowed in PV. Looking at packages/linux shows they can be used but extreme caution is recommended (see pitfalls below). They wouldn't be allowed under Debian rules if PR wasn't specificed but since OE always sets PR by default, hyphens are allowed by default.
| |
| − |
| |
| − | == SCM-based packages ==
| |
| − | | |
| − | When building software from a non-release version fetched from git, use the following:
| |
| − | | |
| − | <code>
| |
| − | PV = "<version>+git${SRCPV}"
| |
| − | </code>
| |
| − | | |
| − | Where <code><version></code> is the most recent release version number prior to the revision being fetched. SRCREV should be set to point to the revision to fetch; if the specified revision is not on the master branch, specify the branch in the SRC_URI entry with <code>;branch=<branchname></code>
| |
| − | | |
| − | The recipe file should be named <code><basename>_git.bb</code>.
| |
| − | | |
| − | Similar patterns should be used for recipes fetched from Subversion and other SCMs.
| |
| − | | |
| − | == Pitfalls ==
| |
| − | | |
| − | Prerelease packages such as
| |
| − | | |
| − | * foo_2.4.4rc2
| |
| − | * foo_2.4.4b1
| |
| − | * foo_2.4.4-git5
| |
| − | * foo_2.4.4-pre1
| |
| − | | |
| − | cause a lot of trouble with package managers when the final ''foo_2.4.4'' gets released. So we should use the following:
| |
| − | | |
| − | * foo_2.4.3+2.4.4rc2
| |
| − | | |
| − | [[Category:Policy]]
| |
Latest revision as of 15:28, 30 August 2023
This page has moved to the Yocto Documentation Contributors Guide
