[Proj] (moved to) https://github.com/OSGeo/proj-datumgrid

[Greg Troxel]

Sebastiaan Couwenberg <sebastic at xs4all.nl> writes:

> On 12/19/2017 02:28 AM, Greg Troxel wrote:
>> Even Rouault <even.rouault at spatialys.com> writes:
>>>> Ah sorry for reinventing the wheel, we should probably just
>>>> push your repo
>>>
>>> Done:
>>> https://github.com/OSGeo/proj-datumgrid
>> 
>> What is the plan for how these bits are used?
>
> Primarily to produce the proj-datumgrid archives alongside proj.
>
>> It seems obvious to me that they should be released with version numbers
>> and enough of a packaging system that they can install into
>> ${prefix}/share/proj/? or something, so that packaging systems can make
>> packages (one, separate?), for installation by use by end users.
>
> For now the proj build system is still expected to install the gridshift
> files. This could possibly be separated in the future.

My real question is about the flow from repositories to releases of
tarballs to packaging system packages to bits in users' filesystems.  It
seems (but I could well be confused) that the points of proj-datumgrid
are

  - allow separate update cycle from proj proper
  - make size of proj itself smaller

Right now the pkgsrc proj package includes both proj and
proj-datumgrids.  That's perfectly workable, except that the version of
datumgrids isn't represented in the packaging system, which is perhaps
only cosmetic.

Is that how you think we should be doing things?   Or should the
datumgrids be a separate package, depending on proj, with its own
version?

Greg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 162 bytes
Desc: not available
Url : http://lists.maptools.org/pipermail/proj/attachments/20171220/35dd3b74/attachment.pgp