Hi,
I noticed that in an installation of openldap-ltb 2.4.30 the libraries are in the form:
"libldap-2.4.so.2" etc.
However, in an installation of a pre-30 (e.g. openldap-OPENLDAP_REL_ENG_2_4-eb3ea42.tar.gz with LTB 2.4.28 src.rpm on Centos 5.7 64bit) I see that libraries are in the form:
"libldap-2.4-releng.so.2" etc.
I guess these differences between the (names of the) libraries of the official release and the REL_ENG are intentional. (Probably to emphasize the fact that the package is not final.)
***The Question***: What should we change so as to build the package as a normal (i.e. non-test) package?
This will allow better compatibility on the system (where the package is tested), because packages built with ldap lib dependencies expect the same ldap lib names (liblber-2.4.so.2 and libldap-2.4.so.2).
I would expect some "test" parameter in build/version.var, but I didn't see any.
An easy solution could be to edit build/version.sh to remove "-releng", but I don't think this is the best approach.
Please advise.
Thanks, Nick
On 30/3/2012 3:04 μμ, Nick Milas wrote:
I would expect some "test" parameter in build/version.var, but I didn't see any.
Hmm, I guess I could simply change (in build/version.var):
ol_patch=X
from X to e.g. 29a or to 29.1 ?
Would one of these (which?) or other similar solution (which?), work OK to create a normal package (using a src.rpm) which the system will understand as a pre-30 version (so it can now be used to upgrade (using rpm) e.g. current v2.4.29 and a 2.4.29.2 (or 2.4.29b) or 2.4.30 rpm package can also be used to upgrade later?
Thanks, Nick
Nick Milas wrote:
On 30/3/2012 3:04 μμ, Nick Milas wrote:
I would expect some "test" parameter in build/version.var, but I didn't see any.
Hmm, I guess I could simply change (in build/version.var):
ol_patch=Xfrom X to e.g. 29a or to 29.1 ?
Would one of these (which?) or other similar solution (which?), work OK to create a normal package (using a src.rpm) which the system will understand as a pre-30 version (so it can now be used to upgrade (using rpm) e.g. current v2.4.29 and a 2.4.29.2 (or 2.4.29b) or 2.4.30 rpm package can also be used to upgrade later?
Test builds are not meant to be packaged.
On 30/3/2012 4:27 μμ, Howard Chu wrote:
Test builds are not meant to be packaged.
Even if it is so, in practice I use packaged builds for testing because in this way I can control better what happens to the system and manage versioning. Since I'm using LTB src.rpm's, this helps me ensure that all system components are updated correctly and that OpenLDAP is built correctly too for my environment.
In any case, even if I am following a non-standard procedure *for private use*, can you please tell me: if I change ol_patch=X to ol_patch=29.1 will it work OK with the build system? Or, can you please suggest what should I do to specify proper version numbering for versions between e.g. 2.4.29 and 2.4.30 (e.g. 2.4.29.1 etc.)?
Thanks, Nick
Nick,
Nick Milas schrieb (30.03.2012 16:08 Uhr):
On 30/3/2012 4:27 μμ, Howard Chu wrote:
Test builds are not meant to be packaged.
Even if it is so, in practice I use packaged builds for testing because in this way I can control better what happens to the system and manage versioning. Since I'm using LTB src.rpm's, this helps me ensure that all system components are updated correctly and that OpenLDAP is built correctly too for my environment.
That's what I do, too.
In any case, even if I am following a non-standard procedure *for private use*, can you please tell me: if I change ol_patch=X to ol_patch=29.1 will it work OK with the build system? Or, can you please suggest what should I do to specify proper version numbering for versions between e.g. 2.4.29 and 2.4.30 (e.g. 2.4.29.1 etc.)?
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.
Marc
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
On 30/03/2012 15:27, Howard Chu wrote:
Nick Milas wrote:
On 30/3/2012 3:04 μμ, Nick Milas wrote:
I would expect some "test" parameter in build/version.var, but I didn't see any.
Hmm, I guess I could simply change (in build/version.var):
ol_patch=Xfrom X to e.g. 29a or to 29.1 ?
Would one of these (which?) or other similar solution (which?), work OK to create a normal package (using a src.rpm) which the system will understand as a pre-30 version (so it can now be used to upgrade (using rpm) e.g. current v2.4.29 and a 2.4.29.2 (or 2.4.29b) or 2.4.30 rpm package can also be used to upgrade later?
Test builds are not meant to be packaged.
While this is true, and such packages should not be distributed, it can be useful to package test versions to help test them against real world applications, before the test version is released, thus potentially helping to find bugs.
The versioning system of RPM is rather off-topic here, but AFAIK (and I've spent some time searching) there is no mecanism in RPM to say "this is a development build, the version number is < 2.4.30", except to use a "Epoch: " field in the spec file. As you're using LTB packages, I suggest moving this part of the discussion to the ltb-dev mailing list.
Jonathan
openldap-technical@openldap.org
-
Howard Chu -
Jonathan Clarke -
Marc Patermann -
Nick Milas