On 2/4/2012 11:41 πμ, Marc Patermann wrote:
That's what I do, too. ...
I just change ol_patch to the next version, like 31, and set the rpm version in my spec file to something like 000 to indicate this is a pre version package. This works for me.
Thanks Marc and Buchan,
In the meantime, I tested it myself.
I downloaded the latest REL_ENG (http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=snapshot;h=e911e7a...); This produced openldap-e911e7a.tar.gz.
Then I changed ol_patch=X to ol_patch=30.1 (and repacked openldap-e911e7a.tar.gz as openldap-2.4.30.1.tgz).
Then I used (as usual) LTB-OpenLDAP src.rpm (v2.4.30) and changed in openldap-ltb.spec:
%define real_version 2.4.30.1
I built successfully and installed (using rpm -Uvh, upgrading from the official release v2.4.30):
openldap-ltb-2.4.30.1-1.x86_64.rpm openldap-ltb-contrib-overlays-2.4.30.1-1.x86_64.rpm openldap-ltb-debuginfo-2.4.30.1-1.x86_64.rpm
Everything worked OK.
(So, I can testify that the current REL_ENG works OK too - at least for my setup.)
In future upgrades (e.g. with some next REL_ENG, before final 2.4.31), I believe it would be fine (for yum/rpm) to similarly produce:
openldap-ltb-2.4.30.2-1.x86_64.rpm
I guess I could have also used your approach, in which case I should change:
ol_patch=31
and in openldap-ltb.spec:
%define real_version 2.4.31 %define release_version 1%{?dist}
and it would be OK too. In future upgrades, it would be enough to change:
%define release_version 2%{?dist}
to allow for correct rpm/yum updates.
So, with any of the above methods, we would:
1. Avoid the problem of producing incompatible "-releng"-named libraries. 2. Be able to use rpm/yum for versioning and management.
Best regards, Nick