Re: [x264] Update to 0.148-20160924-86b7198 version
2016-09-26 18:34 GMT+02:00 Sérgio Basto <sergio(a)serjux.com>:
On Seg, 2016-09-26 at 11:59 +0200, Nicolas Chauvet wrote:
> 2016-09-24 5:39 GMT+02:00 Sérgio M. Basto <sergiomb(a)rpmfusion.org>:
> >
> > commit 36ac6ae0d5cb72b37ba60a8dc69eae3b147e0935
> > Author: Sérgio M. Basto <sergio(a)serjux.com>
> > Date: Sat Sep 24 04:31:21 2016 +0100
> >
> > Update to 0.148-20160924-86b7198 version
> > %endif
--- a/x264.spec
+++ b/x264.spec
@@ -1,7 +1,7 @@
-# globals for x264-0.148-20160614-a5e06b9.tar.bz2
+# globals for x264-0.148-20160924-86b7198.tar.bz2
%global api 148
-%global gitdate 20160614
-%global gitversion a5e06b9
+%global gitdate 20160924
+%global gitversion 86b7198
%global snapshot %{gitdate}-%{gitversion}
%global gver .%{gitdate}git%{gitversion}
%global branch stable
@@ -29,8 +29,8 @@
Summary: H264/AVC video streams encoder
Name: x264
-Version: 0.%{api}
-Release: 11%{?gver}%{?_with_bootstrap:_bootstrap}%{?dist}
+Version: 0.%{api}%{?gver}
+Release: 1%{?_with_bootstrap:_bootstrap}%{?dist}
Version: 0.148.20160924git86b7198-1
vs live555 Version: 2016.07.19
Version 0.148 is useful, you suggest 0.148.2016.09.24.git86b7198-1 ? ,
also git hash is useful ... or like this 0.148.20160924.86b7198-1
without git world ?
yeah I think version should be with date of the source and git
shortcommit : %{gitdate}.git%{shortcommit} this should be part of
version, if not, one day we are in 0.148-117 and counting, is like
rtmpdump.spec ! , the version almost stopped , so our version should
include %{gitdate}.git%{shortcommit} .
This is approved ?
No I'm sorry, I should have been more accurate.
Packaging guideline mandate that the snapshot date and/or git hash to
be in the release field.
for x264 the version is 0.148 as reported by the upstream version.sh
script. we could add the X264_REV field, but I'm not sure if it's
sorted, so it might not be relevant as a RPM Version field (as later
version won't be higher).
So basically I'm asking to revert back to the previous version - release scheme.
Why I've mentioned live555 is because it's the same as x264 in the
sense that SONAME is the same since few time already but previously
there were no enforcement that the version installed at runtime is
high enough.
It is done by dropping a RPM macro in the live555-devel that is later
re-used by packages using live555 (mainly vlc). Since this macro is
used at build time, this enforce that the live555 version used at
build time is the same at runtime (but it could be >= instead of ==).
I don't know why you thought it was important to change the version
field in x264, but this seems a better approach.
Thx
--
-
Nicolas (kwizart)