[Swan-dev] comment on version.mk - make rpm

[Paul Wouters]

On Fri, 20 Dec 2019, Antony Antony wrote:

> It seems it was not easy to understand in previous messages and there is
> some interest to make rpm version string better. A correct version number
> would help when working on several versions.
> The solution appears to be simple as far as I see it, yet very hard to
> explain.
>
> In short, I think a new version.mk should not be created when running "make
> rpm" instead use IPSECVERSION=%{IPSECVERSION} in specfile, or something A
> similar. see git show b68c5a33261ea0

The attempt is to not try and edit anything in libreswan.spec or the
environment other than the Version: and prever: values which are the only
changes that a full release makes to the shipped spec file. This ensures
"make rpm" and the release process is as identical as possible.

>>> However, there is another way to set pluto --version,
>>> IPSECVERSION=%{IPSECVERSION}
>>> https://github.com/libreswan/libreswan/blob/master/packaging/fedora/libreswan-testing.spec#L18
>>>
>>> setting IPSECVERSION is also used in Debian and OpenWRT packaging. May be it
>>> is better to use this method instead of b68c5a.

That allows for the spec file Version: and spec file global IPSECVERSION
to get out of sync. It is not good to have versioning information in two
places. Similarly, the version.mk and spec file version could be
different, and I'd like to avoid that, but version.mk is also changed in
the regular release, so this method most closely mimics a normal
release.

> There is no hardcoded IPSECVERSION in the libreswan-testing.spec !
> That was fixed a while ago. Now only have to change the "Version" by
> "make kvm-rpm" target.

If I remember correctly, your copy of the spec file created does.

> The tarball has no file with hardcoded IPSECVERSION=3.30. 3.30 would be in
> the spec file as Version.

But every tar ball contains mk/version.mk. It should be the correct one.
If someone rebuilds it via: rpmbuild -ba ~/rpmbuild/SPECS/libreswan.spec
after installing the src.rpm, it should not build different because of
some IPSECVERSION environment variable not being set.

> It is important that rpm version as well as version pluto report to be the
> sam.  Not something that look alike.

Here we have a slightly different view. It is not expected to be string
identical. For example:

paul at bofh:~$ openssl version
OpenSSL 1.1.1 FIPS  11 Sep 2018
paul at bofh:~$ rpm -q openssl
openssl-1.1.1-8.el8.x86_64
paul at bofh:~$

The version of the software and the version-release of the software are
two differet things.

> The solution I proposed and used in kvm-rpm has rpm-version and pluto
> version the same.
>
> make rpm
> Wrote: /home/build/rpmbuild/RPMS/x86_64/libreswan-3.28-0.rc1275_gf42dab7174_master.x86_64.rpm
> Wrote: /home/build/rpmbuild/RPMS/x86_64/libreswan-debugsource-3.28-0.rc1275_gf42dab7174_master.x86_64.rpm
> Wrote:
> /home/build/rpmbuild/RPMS/x86_64/libreswan-debuginfo-3.28-0.rc1275_gf42dab7174_master.x86_64.rpm

By creating -0 releases you cause a problem for upgrading versions. eg
3.28-0.rc1275_gf42dab7174 versus 3.28-0.rc800_gXXXXXXX.

> 3.28-0.rc1275_gf42dab7174_master != v3.28-1275-gf42dab7174-master

One number has the "rpm release" in it, to ensure any later version will
properly be seen as "higher" version to upgrade.

> Note extra "rc" and "- != _"

you cannot have "-" in an upstream version as it confuses rpm since it is the
seperator between Release and Version. Any "-" in an upstream version is
converted to "_" by design by Fedora/RHEL Packaging Guidelines.

The rc (or probably better: dr) should be there to show this is not a full
release. Currently, this is indeed a problem as it should generate
something like:

3.28dr0-0.1275_gf42dab7174

So the next release can be:

3.28dr0-0.1276_gXXXXXXX

and it will properly rpm upgrade.

but this does require the tar ball to be in directory libreswan-3.28dr0/
and multiple different sources would have the same tar ball. Which is
bad. That could be addresed by shipping with libreswan-3.28drXXXX/ which
results in 3.28-0.drXXXX rpm version with 3.28drXXXX pluto version.

It would still cause a weirdness for our real 3.28dr1 versus an
automated 3.28drXXXX version. We could use a different prever prefix
for automated builds (eg "3.28abXXXX")

> now try
> make kvm-rpm
>
> Wrote: /root/rpmbuild/RPMS/x86_64/libreswan-3.28_1275_gf42dab7174_master-1.fc30.x86_64.rpm
> Wrote: /root/rpmbuild/RPMS/x86_64/libreswan-debugsource-3.28_1275_gf42dab7174_master-1.fc30.x86_64.rpm
> Wrote:
> /root/rpmbuild/RPMS/x86_64/libreswan-debuginfo-3.28_1275_gf42dab7174_master-1.fc30.x86_64.rpm
>
> /usr/local/libexec/ipsec/pluto --version
> Libreswan 3.28_1275_gf42dab7174_master-1
>
> 3.28_1275_gf42dab7174_master-1 = 3.28_1275_gf42dab7174_master-1

Sure it is equal, but it is NOT a valid rpm version. What do you think happens when
3.28 final release comes out and ends up in the user's repository. Will
it automatically upgrade or not ? Is "3.28" < or > than "3.28_1275_gf42dab7174_master" ?
What about "3.28rc1" ?

> Tuomo would probably argue this not a good version string

I hope so :)

> My idea is what we see on rpm file name should be the same in output of
> pluto --version.

That is not a correct assumption. See above.

> To get that you need something like "IPSECVERSION=%{IPSECVERSION}" in the
> spec file, creating version.mk will not work.
>
> I gues Tuomo is suggesting fix "make showrpmversion" "make showrpmrelease"
> and use this.
>
> make showrpmversion
> 3.28_1275_gf42dab7174_master

This is a _bad_ version. a pre-release for 3.28 MUST start with a
release number of 0. followed by something that would increase. So
that once the final release comes out, it can have release number 1.

> make showrpmrelease
> 1275-gf42dab7174-master

There cannot be a "-" in there.

> I am not sure how a typical user re-build with increased version. Would you
> change Release or Version? or change something else in the spec file.

It really depends on how the tar ball is build.

> And "IPSECVERSION=%{IPSECVERSION}" appear to  work with one change.

It does not and breaks the upgrade path.

Paul