Description of problem: Starting from version 1.8.0 GRIB API, definition files versions are distributed separately to allow frequent updates of the decoding rules (definition files) for the same decoding engine (library). Please note that using the definition files with a version of the library different from the one indicated as compatible will cause some problems in decoding/encoding. Definition files version 1.8.0.1 are available for free download from http://www.ecmwf.int/products/data/software/download/grib_api.html Grib_api configure do not provide shared library and this is no goood. Actual results: A lot of bugs due to old grib_api version in package. User executables are static linked with grib_api library Is not possible to upgrade def files Expected results: In attachments you can find our rpms in use at our meteorological service. I suggest an upgrade to the last version of grib_api. The structure of grib_api and grib2 is intended for a rapid update of def files and the possibility to modify and add more local definition. So I suggest to split package in two differnet packages, one for def files only. Also there is a patch for generate shared library. Additional info: in attachments you can find two source RPM with all those problem solved! Paolo Patruno
Created attachment 364733 [details] grib_api new source rpms grib_api new source rpms
Created attachment 364734 [details] new grib_def SRPM file new grib_def SRPM file
I personally think that the patches should go upstream first, though I am not the maintainer anymore. Apart from that, packages should indeed be split and updated.
The patch was submitted to upstream but not fully accepted for a portability problem on proprietary platform. The patch is the same used by debian mantainer; we are working together in link with developer to distribute grib_api.
Rereading the review request (and my hard disk :) I found that the debian maintainer already contacted me with the patch, and I noted that upstream agreed in principle with the change. (Bug 427121#c4). What the debian maintainer Enrico Zini said in a mail, at that time was about the same than what you propose: The major change I did was patching the library (patch included) to generate a shared library. Enrico Fucile has not included the patch yet because libtool has problems on their IBM Power5 platform; otherwise, he's happy with the patch. If you would like to ship a shared library with Fedora as well, we should keep in touch with regards to soname versioning, so that when upstream finally integrates libtool they can just use the soname versions of Fedora and Debian. (Enrico Fucile is the upstream maintainer). It was in 2008-03-02, so I think that upstream is still not ready and, in my opinion, it means that we still should wait and work with upstream for the integration of the shared libraries. It is likely that upstream will use sonames consistent with what is in debian, but, in doubt, I wouldn't use the patch. Here is part of what I answered to Enrico Zini: Looks good. More important is not that we are synchronized, but that Enrico Fucile accepts to use our versionning...
Hello. In the end, in Debian I adapted the libtool patch to adopt a versioning scheme that will not conflict with upstream. The discussion can be found at: http://lists.debian.org/debian-devel/2009/03/msg00927.html with the most important messages being these two: http://lists.debian.org/debian-devel/2009/03/msg00984.html http://lists.debian.org/debian-devel/2009/03/msg01019.html This way, when upstream will decide to package a shared library, we just go through a normal rename. There are two other minor patches that I added to the Debian package, one to prefer gfortran over pgf90, and one to use Automake conditionals to have a working make dist. You can find here the whole set: http://git.debian.org/?p=collab-maint/gribapi.git;a=tree;f=debian/patches;h=22f0dbd3e2423dfc637059f8deca7c70ed81fa24;hb=HEAD feel free to help yourself :)
(In reply to comment #6) > Hello. > > In the end, in Debian I adapted the libtool patch to adopt a versioning scheme > that will not conflict with upstream. The discussion can be found at: > http://lists.debian.org/debian-devel/2009/03/msg00927.html > with the most important messages being these two: > http://lists.debian.org/debian-devel/2009/03/msg00984.html > http://lists.debian.org/debian-devel/2009/03/msg01019.html Interesting way out. > This way, when upstream will decide to package a shared library, we just go > through a normal rename. That means a planned useless change in soname or keeping the distribution specific soname until upstream breaks the ABI. Both are acceptable, but I think that changing the soname once upsteram adds shared library support is the best (of course, in case of fedora this should be done in rawhide only). What's your opinion? This whole issue is certainly worth reporting on the distributions list. As a side note, I think that if we use a distro specific soname and change the soname as soon as upstream add support for shared libraries (which I believe is the best), even if there hasen't been an ABI change it would be better if static libs were shipped together with the shared libs, not for the distribution, but for the users who want to avoid recompilation when the soname changes while the ABI doesn't. If static libs are kept as long as upstream doesn't support shared libraries, I support this patch. And I'll do a mail to the distributions list after comments have been done. > There are two other minor patches that I added to the Debian package, one to > prefer gfortran over pgf90, and one to use Automake conditionals to have a > working make dist. Those doesn't seem to be problematic, but should go upstream. Did you sent them?
(In reply to comment #7) > (In reply to comment #6) > > This way, when upstream will decide to package a shared library, we just go > > through a normal rename. > > That means a planned useless change in soname or keeping the distribution > specific soname until upstream breaks the ABI. Both are acceptable, but I think > that changing the soname once upsteram adds shared library support is the best > (of course, in case of fedora this should be done in rawhide only). What's your > opinion? The C API and ABI are extremely simple and in theory also stable, as there is quite a bit of software at ECMWF that starts to be built on grib_api. So this, in the most probably case, gives us only one useless change when upstream adds shared library support. In the worst case, upstream breaks ABI and we have an extra change, but in my experience there are far worse upstreams in terms of ABI stability. As you say, we could delay the useless soname change until upstream breaks ABI, but I agree with you that it's best to align with upstream and remove the extra patch as soon as it's possible to do so. After the infamous Debian openssh issue, it's become quite trendy to keep distribution specific patches well isolated and as little as possible. So, I think we agree on everything here. > the best), even if there hasen't been an ABI change it would be better if > static libs were shipped together with the shared libs, not for the > distribution, but for the users who want to avoid recompilation when the soname > changes while the ABI doesn't. > > If static libs are kept as long as upstream doesn't support shared libraries, I > support this patch. And I'll do a mail to the distributions list after comments > have been done. What do you mean with "static libs shipped together with the shared libs"? In Debian I have to follow rather strict policies on library packaging, and I don't think I can do much besides building the usual libgrib-api-dev with the static library and a libgrib-api-0d-0 for the shared library. I don't see a problem with it, though. I'm however deliberately not putting the library version in the development package name (that is, I'm not doing a libgrib-api-0d-dev), so that it won't need to be changed once we drop the '0d' and go with what upstream uses. Dependencies on shared libraries are autogenerated at package build time, so the whole migration when 0d is dropped should amount to not much more than triggering an automatic rebuild of a few packages. > > There are two other minor patches that I added to the Debian package, one to > > prefer gfortran over pgf90, and one to use Automake conditionals to have a > > working make dist. > > Those doesn't seem to be problematic, but should go upstream. Did you sent > them? Oh yes. Also, at every new upstream release I port those patches and send the updated version to upstream, who is however always busy with some very high priority task and tends to have no time to review them. With 1.8.0 I tried to beg for at least the Automake conditionals patch to be accepted, since it's clearly uncontroversial; let's hope to see it happen in the next version.
This would require a review request for grib_def
If you're interested, please take a look at https://bugzilla.redhat.com/show_bug.cgi?id=529527
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.