Document the existence of the EXTRAVERSION field and the information expected to be present in it.
Signed-off-by: Kevin O'Connor kevin@koconnor.net --- docs/Build_overview.md | 15 +++++++++++++++ 1 file changed, 15 insertions(+)
diff --git a/docs/Build_overview.md b/docs/Build_overview.md index 26db226..ac38694 100644 --- a/docs/Build_overview.md +++ b/docs/Build_overview.md @@ -52,6 +52,21 @@ CSM_ENABLE'. The SeaBIOS binary will be included as a discrete file within the 'Flash Volume' which is created, and there are tools which will extract it and allow it to be replaced.
+Distribution builds +=================== + +If one is building a binary version of SeaBIOS as part of a package +(such as an rpm) or for wide distribution, please provide the +EXTRAVERSION field during the build. For example: + +`make EXTRAVERSION="-${RPM_PACKAGE_RELEASE}"` + +The EXTRAVERSION field should provide the package version (if +applicable) and the name of the distribution (if that's not already +obvious from the package version). This string will be appended to the +main SeaBIOS version. The above information helps SeaBIOS developers +correlate defect reports to the source code and build environment. + Overview of files in the repository ===================================
If building from an official tarball and EXTRAVERSION info is provided, then consider the build to be "clean" (don't include hostname/build timestamp). This is done on the expectation that EXTRAVERSION will have enough information to allow developers to find the builder and build environment should a defect be reported, and therefore the hostname/timestamp is not necessary.
Signed-off-by: Kevin O'Connor kevin@koconnor.net --- scripts/buildversion.py | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/scripts/buildversion.py b/scripts/buildversion.py index bceae63..d61fc9e 100755 --- a/scripts/buildversion.py +++ b/scripts/buildversion.py @@ -23,7 +23,8 @@ def git_version(): return "" return ver
-# Look for version in a ".version" file +# Look for version in a ".version" file. Official release tarballs +# have this file (see scripts/tarball.sh). def file_version(): if not os.path.isfile('.version'): return "" @@ -90,9 +91,14 @@ def main(): cleanbuild, toolstr = tool_versions(options.tools)
ver = git_version() - cleanbuild = cleanbuild and ver and 'dirty' not in ver + cleanbuild = cleanbuild and 'dirty' not in ver if not ver: ver = file_version() + # We expect the "extra version" to contain information on the + # distributor and distribution package version (if + # applicable). It is a "clean" build if this is a build from + # an official release tarball and the above info is present. + cleanbuild = cleanbuild and ver and options.extra != "" if not ver: ver = "?" if not cleanbuild:
On Do, 2015-10-22 at 12:20 -0400, Kevin O'Connor wrote:
Document the existence of the EXTRAVERSION field and the information expected to be present in it.
Signed-off-by: Kevin O'Connor kevin@koconnor.net
docs/Build_overview.md | 15 +++++++++++++++ 1 file changed, 15 insertions(+)
diff --git a/docs/Build_overview.md b/docs/Build_overview.md index 26db226..ac38694 100644 --- a/docs/Build_overview.md +++ b/docs/Build_overview.md @@ -52,6 +52,21 @@ CSM_ENABLE'. The SeaBIOS binary will be included as a discrete file within the 'Flash Volume' which is created, and there are tools which will extract it and allow it to be replaced.
+Distribution builds +===================
+If one is building a binary version of SeaBIOS as part of a package +(such as an rpm) or for wide distribution, please provide the +EXTRAVERSION field during the build. For example:
+`make EXTRAVERSION="-${RPM_PACKAGE_RELEASE}"`
That'll work, but 'make EXTRAVERSION="-%{release}"' is the shorter and more common way to say this.
Difference between %{release} and ${RPM_PACKAGE_RELEASE} is that the former is handled by rpm, i.e. the build script snippet handed over to the shell has this already replaced, whereas the later is handled by the shell by reading RPM_PACKAGE_RELEASE from the environment.
buildversion.py can see the RPM_PACKAGE_RELEASE environment variable too, thats why I picked that one in the context possibly doing rpm build autodetection.
Other that that both patches look fine to me.
cheers, Gerd
On Fri, Oct 23, 2015 at 07:56:06AM +0200, Gerd Hoffmann wrote:
On Do, 2015-10-22 at 12:20 -0400, Kevin O'Connor wrote:
+Distribution builds +===================
+If one is building a binary version of SeaBIOS as part of a package +(such as an rpm) or for wide distribution, please provide the +EXTRAVERSION field during the build. For example:
+`make EXTRAVERSION="-${RPM_PACKAGE_RELEASE}"`
That'll work, but 'make EXTRAVERSION="-%{release}"' is the shorter and more common way to say this.
In the context of an example, however, the ${RPM_PACKAGE_RELEASE} seems a little more descriptive. That is, someone not an expert at RPM should get the gist of it, and an expert at RPM should know enough to use the preferred syntax anyway. I'll change it if you think it should be different though.
BTW, does %release/$RPM_PACKAGE_RELEASE provide the full "-1.fc22" suffix? That's what I'd like to see in the extra version.
Also, it occurred to me that we should also document tarball.sh - I'm thinking adding something like:
If one is building a binary in a build environment that does not have access to the git tool or does not have the full SeaBIOS git repo available, then please use an official SeaBIOS tar file as source. If building from a snapshot (where there is no official SeaBIOS tar) then one should generate a snapshot tar file on a machine that does support git using the scripts/tarball.sh tool. For example:
`scripts/tarball.sh`
The tarball.sh script encodes version information in the resulting tar file which the build can extract and include in the final binary. The above EXTRAVERSION field should still be set when building from a tar.
-Kevin
Kevin O'Connor wrote:
+`make EXTRAVERSION="-${RPM_PACKAGE_RELEASE}"`
That'll work, but 'make EXTRAVERSION="-%{release}"' is the shorter and more common way to say this.
In the context of an example, however, the ${RPM_PACKAGE_RELEASE} seems a little more descriptive. That is, someone not an expert at RPM should get the gist of it, and an expert at RPM should know enough to use the preferred syntax anyway. I'll change it if you think it should be different though.
I agree with you Kevin, I don't think it should be changed.
//Peter
Hi,
In the context of an example, however, the ${RPM_PACKAGE_RELEASE} seems a little more descriptive. That is, someone not an expert at RPM should get the gist of it, and an expert at RPM should know enough to use the preferred syntax anyway.
Makes sense.
BTW, does %release/$RPM_PACKAGE_RELEASE provide the full "-1.fc22" suffix? That's what I'd like to see in the extra version.
Yes.
Also, it occurred to me that we should also document tarball.sh - I'm thinking adding something like:
If one is building a binary in a build environment that does not have access to the git tool or does not have the full SeaBIOS git repo available, then please use an official SeaBIOS tar file as source. If building from a snapshot (where there is no official SeaBIOS tar) then one should generate a snapshot tar file on a machine that does support git using the scripts/tarball.sh tool. For example:
`scripts/tarball.sh`
The tarball.sh script encodes version information in the resulting tar file which the build can extract and include in the final binary. The above EXTRAVERSION field should still be set when building from a tar.
Looks good to me.
cheers, Gerd
On Mon, Oct 26, 2015 at 11:22:01AM +0100, Gerd Hoffmann wrote:
Hi,
In the context of an example, however, the ${RPM_PACKAGE_RELEASE} seems a little more descriptive. That is, someone not an expert at RPM should get the gist of it, and an expert at RPM should know enough to use the preferred syntax anyway.
Makes sense.
BTW, does %release/$RPM_PACKAGE_RELEASE provide the full "-1.fc22" suffix? That's what I'd like to see in the extra version.
Yes.
Also, it occurred to me that we should also document tarball.sh - I'm thinking adding something like:
If one is building a binary in a build environment that does not have access to the git tool or does not have the full SeaBIOS git repo available, then please use an official SeaBIOS tar file as source. If building from a snapshot (where there is no official SeaBIOS tar) then one should generate a snapshot tar file on a machine that does support git using the scripts/tarball.sh tool. For example:
`scripts/tarball.sh`
The tarball.sh script encodes version information in the resulting tar file which the build can extract and include in the final binary. The above EXTRAVERSION field should still be set when building from a tar.
Looks good to me.
Thanks - I committed this (updated) series.
-Kevin
-
Gerd Hoffmann -
Kevin O'Connor -
Peter Stuge