[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: REL_ENG versions produce different libraries?
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=e911e7ad8b82b42a172967760fe6ec4333c57b71;sf=tgz);
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