Bug 647101

Thanks very much for reporting this, Till. I will take care of this issue.

I actually am not sure, if I understood your report right, Till. As far as I understood the documentation, %bcond_with supports passing arguments to the configure script beginning with "--with" or "--without".

I guess when claiming on the readability of the spec file, you mean right that part in the spec file, where the arguments are passed to the spec file? If yes, I can fully understand this and second that. Thus I really appreciate this report and like to improve the package where I can.

The thing I don't understand here is: Does this bcond-thing also support arguments beginning with "--enable" and "--disable"? If so, this actually is not mentioned in the documentation you linked. If not, your criticism on the readability would not apply to the %configure section in the spec file. In that case, which specific section in the spec file do you suggest to improve with this?

I could imagine you mean the BuildRequire stuff from line 15 to 20, but I'm not sure with this and a bit confused anyway. I'd be glad if you could bring a bit more light into this dark. :)

Uh, I did not notice that the with-macros need to be converted into disable/enable strings. I guess this is worth a rpm feature request. But there is one more advantage of using %bcond_with, then one can easily spot at the beginning of the spec, which build conditionals are used and whether they are enabled or disabled by default.

I tried to implement this with

SRPM: http://dmaphy.fedorapeople.org/jabberd2/jabberd-2.2.11-3.fc14.src.rpm

Let me know what you think. :)

Wrote a feature request at the RPM tracker: http://rpm.org/ticket/187. :)

I just noticed the above package won't build in mock because of unresolved dependencies. Seems I just tested the build with 'rpmbuild -ba', that was working because I have the required packages installed anyway. I'll work on this and keep you up-to-date. :)

Guys, some SPEC nits are probably not reason to update package in EPEL-5. WONTFIX?

(In reply to Matěj Cepl from comment #7)
> Guys, some SPEC nits are probably not reason to update package in EPEL-5.
> WONTFIX?

It does not need to be the only change. However, I think it would still be a good idea to do this in Rawhide, so it might get into EPEL-8.

Thanks for bringing this up again.

Unfortunately I don't understand what actually is requested. The conditional build works but the wrong macros are used? Can you describe in more details what is requested? If RPM does not support expand the macros to --enable-something it does not make much sense, from my point of view, to keep this bug open. If something can be made better I am happy to change it or apply a patch (even better). Or somebody else can apply the patch.

jabberd-2.4.0-2.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-85e0b3ae41

jabberd-2.4.0-2.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-85e0b3ae41

This bug appears to have been reported against 'rawhide' during the Fedora 25 development cycle.
Changing version to '25'.

jabberd-2.4.0-2.el7 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report.