Red Hat Bugzilla – Bug 999609
glpk: No way to retrieve iteration count
Last modified: 2013-11-10 10:15:39 EST
Created attachment 788940 [details]
Patch to add a glp_get_it_cnt() function
Description of problem:
The versions of glpk in Fedora up through Fedora 19 still supported the old lpx_* routines and LPX* constants. Those were dropped in the version of glpk now in F-20 and Rawhide. I have ported all of my glpk-using packages over to the new interface, but there is one element of the old API that cannot be ported, namely:
There is simply no element of the glp_* interface that exposes this information. I have one package now in Fedora (latte-integrale) and one package that I am about to submit (cvc4) which make that call. They need an alternative for F-20 and Rawhide.
I am attaching a candidate patch to solve this problem. I will ask upstream to include something like this in the next release. For now, though, would it be possible to add this patch to the Fedora build for the sake of latte-integrale and cvc4?
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Since the requested function will be included in the next version of glpk (see http://lists.gnu.org/archive/html/help-glpk/2013-08/msg00047.html), adding it now is forward compatible. Can this patch please be added? I am still stuck with latte-integrale and cvc4 because of this bug. Thank you.
Should we wrap it in some kind of FEDORA_GLPK_ITCNT macro until it is shipped in a release? Might avoid some cross-distro version<->header confusion. I guess the extra symbol is still there, but there's not too much we can do about that.
Oops, sorry, got busy and let this drop off my radar. I'm not sure what problem wrapping it in a macro would solve. Other software won't expect the symbol to exist, so its existence shouldn't pose a problem. This is strictly a solution to the disappearance of the old API, which is still in widespread use. And it is a forward-compatible solution, at that.
(In reply to Jerry James from comment #4)
> I'm not sure what
> problem wrapping it in a macro would solve. Other software won't expect the
> symbol to exist, so its existence shouldn't pose a problem.
People writing software against Fedora 19 with GLPK vX will find that their software doesn't compile or link against GPLK vX on other distributions. That seems problematic.
Oh, I see. Sorry for being dense. Okay, then wrapping it in a macro seems like a good solution. It will only be necessary until the next glpk release, anyway.
(In reply to Jerry James from comment #6)
> Oh, I see. Sorry for being dense. Okay, then wrapping it in a macro seems
> like a good solution. It will only be necessary until the next glpk
> release, anyway.
No worries. I figure the next release will probably happen pretty soon if it hasn't yet.
From comment #0, you just need this in F-20+, correct?
(In reply to Conrad Meyer from comment #7)
> No worries. I figure the next release will probably happen pretty soon if it
> hasn't yet.
It hasn't. I just checked. If there will be a new release in the next few weeks, I'm fine with waiting for it. But I don't see any indication on the mailing list of when the next release might happen.
> From comment #0, you just need this in F-20+, correct?
Yes, that is correct.
I got an RPATH issue (pretty sure it's unrelated to this change) building locally, but maybe Koji won't choke on that:
Ah, tracking Rpath issue in bug 953012.
Built for F-20, too: http://koji.fedoraproject.org/koji/taskinfo?taskID=6087368
glpk-4.52.1-2.fc20 has been submitted as an update for Fedora 20.
glpk-4.52.1-2.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.