|
From: | Przemek Klosowski |
Subject: | Re: HDF5 library mismatch (switching to the maintainers list) |
Date: | Fri, 11 Feb 2011 10:00:07 -0500 |
User-agent: | Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Lightning/1.0b2 Thunderbird/3.1.7 |
On 02/10/2011 06:00 PM, Jordi GutiƩrrez Hermoso wrote:
On 10 February 2011 16:01, Przemek Klosowski<address@hidden> wrote:because Octave was compiled against HDF5 v.1.8.4 and in the meantime HDF was updated because the dependency in the package is specificed loosely. The abort is actually a preventive measure of the incompatibility testing code in Octave; it's possible to disable the warning by controlling Octave with an environment variable mentioned in the warning:Weren't we discussing in the maintainers mailing list how the Octave rpm packages need some love? Can you do any of that? Do you need help with it?
There are two issues here: packaging, and the actual technical issue with HDF. As to the latter, which I believe is relevant to all distributions of Octave, the code implements a version check which on the surface appears to be overly strict: essentially it warns of the possibility of a crash and then proceeds to abort the program itself. There is an environment variable that avoids that abort, but it has to be set before starting Octave, so it's an usability issue.
I guess the thinking is that it's better to abort the program than to possibly return incorrect data. If people agree that this is the correct thing to do, I think we should change packaging so that Octave 'requires' the version of HDF5 that it was built against. I think Fedora packaging system would trigger a rebuild of Octave in this case. Jussi Lehtola suggested a packaging fix in my bugzilla entry for this problem, https://bugzilla.redhat.com/show_bug.cgi?id=676707
Alternatively, from the usability point of view, I belive it would make sense to NOT abort octave, but issue the warning and either return nothing from the 'load' (overridable by a runtime configuration option), or proceed anyway (if we crash, we crash, and if the data is bad, well, there was a warning :).
About the general packaging issue, Octave RPM packages are managed by Jussi Lehtola, Alex Lan(?), mmahut (?) @Redhat and Rakesh Pandit. I try to help by submitting bugs: in bugzilla when it looks like a packaging issue, and to Octave's tracker otherwise. I wouldn't mind applying to become a co-packager for Octave, if people here felt that it would help.
Could you point me to the list of RPM packaging issues that need attention?
[Prev in Thread] | Current Thread | [Next in Thread] |