Spec Name or Url: http://www.cora.nwra.com/~orion/fedora/libproj4.spec SRPM Name or Url: http://www.cora.nwra.com/~orion/fedora/libproj4-050319-1.fc6.src.rpm Description: This library supports over 170 projections including many used in national grid systems. Many more projections are available by selection of appropriate values for control parameters of current base projections. Circa 2002 the libproj4 system is an outgrowth of the author's PROJ.4 system and corrected inconsistencies of the old system and improved overall operation. It also ensured that identifier namespace became restricted to PJ_*/pj_*. The old PROJ.4 system is still available at some web sites such as Remote Sensing Organization site. The web sites associated with PROJ.4 may have performed their own modification to the PROJ.4 library so there is no guarantee of the same collection of projections nor functional equivalence.
> %post -p /sbin/ldconfig > > %postun -p /sbin/ldconfig > > %files > %defattr(-,root,root,-) > %doc manual.pdf > %{_bindir}/lproj Huh? /sbin/ldconfig but no libs? > %files devel > %defattr(-,root,root,-) > %{_includedir}/lib_proj.h > %{_libdir}/libproj4.so Is this shared lib supposed to be linked to and available at run-time? In that case it is included in the wrong package. And it is poorly named. On the contrary, the PROJ.4 system uses a versioned soname. > %doc manual.pdf This aims at developers and should be moved into the -devel package.
Any response to Michael's comments?
Still no response; setting NEEDINFO. I will close this ticket soon if there is no further progress.
Sorry for the delay. Got an update here: http://www.cora.nwra.com/~orion/fedora/libproj4.spec http://www.cora.nwra.com/~orion/fedora/libproj4-050319-2.src.rpm * Mon Jul 9 2007 - Orion Poplawski <orion.com> - 050319-2 - Move .so to main package and manual to -devel. Upstream makes no provision for a versioned soname. As I understand it, it is problematic to add one in case upstream decides on a different scheme later on.
>The old PROJ.4 system is still available at some web sites such > as Remote Sensing Organization site. The web sites associated with PROJ.4 > may have performed their own modification to the PROJ.4 library so there is > no guarantee of the same collection of projections nor functional equivalence. Hold on a bit, lets clarify first please. First, proj.4 passed incubation at osgeo.org and ATM is the main library for whole osgeo.org suite. Libproj4 is a bit too early, proj4 _is_ alive and getting love but at this time with joint efforts of osgeo.org: http://trac.osgeo.org/proj/ Second, ask osgeo.org chairman opinion (Frank Warmerdam): cbalint> folks, what is the diff btwn: http://members.verizon.net/~vze2hc4d/proj4/ and http://trac.osgeo.org/proj/ ?! FrankW> libproj4 is Geralds version of proj.4 that focuses on only projections. FrankW> The long term plan is to refactor proj.4 to use it, withproj.4 providing initialization files, datums, and other high level coordinate system services <FrankW> but for the time being, you are generally best off using proj.4 unless you really want to try one of Gerald's new bits of work. cbalint> FrankW, is it sure that osgeo will rebase on that libproj ? Might be matacrs related ? <FrankW> It is not sure. <FrankW> It is just my intention (and Geralds). <FrankW> But I've intended to do it for some time and it hasn't happened yet. <cbalint> FrankW, thanks for quick response. <FrankW> Certainly it will be within the metacrs project if it occurs. Clearly its too early. If import this to fedora will create more schizo' for following packages: - ogdi - gdal - grass - mapserver - qgis A bounch of other real struggling issues, a bit dataset related, let me introduce: Its enough that we/I have problem with projections database (EPSG) (i am unsatisfied, but I might wait metacrs instead) since there are 2 variants of .csv sets one for proj.4 and one for gdal in .csv format as geodetic datas, best should be to emmit a new 'epsg-dataset' fedora one called package to unify and be able respin any time any fresh epsg sets for fedora purpose and share it commonly to any package that use it it (grass/gdal/proj), its doable, and this mini=project might go metacrs upstream, unless metacrs have far way better solution and decide to rewrite all api's handling these issues of datasets. I dont really like how epsg datas are derived now into .csv, I was talking with EPSG in particular how to choose best TransformationParams for a projection to avoid duplicates, a problem where gdal choosed to drop and avoid to threat the problem (one main issue). I work on this within elegand solution using EPSG-pgsl->sqlite->.csv with a fancy logic to generate our epsg-dataset A third one problem, related to this libproj4 especialy one that induce confusion in lower functional layers (i mean here not database but how math libraries (I mean libroj4 itself) will probaly induce more problems, i even dont want to think it. Please see if interested what metacrs is related: http://wiki.osgeo.org/wiki/MetaCRS
My statements are really functionality related. Again i personaly would't like this package just for sake of its existence in fedora. However lets debate this issue. //cristian.
Why is the "fedora-review" flag set on this?
I believe because back in the day, that is what one did when one submitted a review. I don't have a burning need for this to be in Fedora. But gdl uses this library rather than the main PROJ.4 distribution. Actually, gdl uses a very old version (now) of libproj4, so we'll see where that moves. I'll close for now.