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@xxxxxxxxxx>
---
If this patch gets accepted, I'll propose the same changes for
osinfo-db-tools.
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
purposes.
---
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
--
2.20.1
_______________________________________________
Libosinfo mailing list
Libosinfo@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libosinfo
