[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-

Then I used (as usual) LTB-OpenLDAP src.rpm (v2.4.30) and changed in openldap-ltb.spec:

   %define real_version

I built successfully and installed (using rpm -Uvh, upgrading from the official release v2.4.30):


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:


I guess I could have also used your approach, in which case I should change:


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,