[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[Libosinfo] [libosinfo PATCH] spec: Add build_timestamp to the Release

The upstream spec file is used for anything else than local builds
and/or as a reference for the downstream spec file.

Knowing that, let's add a build_timestamp to its Release tag so we could
generate builds (either via ./prepare-release.sh or, possibly, taking
advantage of Copr infrastructure) for the project that can be easily
updated every new build and also doesn't clash with the Fedora official
builds*. This change may be really helpful for testing management apps
code depending on to-be-released libosinfo code.

*: The release number was changed from 1 to 0 as official Fedora releases
will always use 1. Meaning that users wouldn't face any issue upgrading
from a custom generated build to a Fedora official one.

Signed-off-by: Fabiano Fidêncio <fidencio redhat com>
If this patch gets accepted, I'll propose the same changes for

I'm not totally sure whether I can easily trigger a new Copr build based
on commit changes as it'd require a .spec and not a .spec.in, but having
this patch in would already help people doing local builds for testing
 libosinfo.spec.in | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/libosinfo.spec.in b/libosinfo.spec.in
index fd7e55c..f75e31d 100644
--- a/libosinfo.spec.in
+++ b/libosinfo.spec.in
@@ -1,9 +1,11 @@
 # -*- rpm-spec -*-
+%define build_timestamp %(date +"%Y%m%d%H%M%s")
 Summary: A library for managing OS information for virtualization
 Name: libosinfo
 Version: @VERSION@
-Release: 1%{?dist}
+Release: 0.%{?build_timestamp}%{?dist}
 License: LGPLv2+
 Group: Development/Libraries
 Source: https://releases.pagure.io/%{name}/%{name}-%{version}.tar.gz

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]