public inbox for [email protected]  
help / color / mirror / Atom feed
GDAL package naming question
2+ messages / 2 participants
[nested] [flat]

* GDAL package naming question
@ 2016-08-17 17:52  John Harvey <[email protected]>
  0 siblings, 1 reply; 2+ messages in thread

From: John Harvey @ 2016-08-17 17:52 UTC (permalink / raw)
  To: pgsql-pkg-yum

Hello folks,

I had a question about the GDAL package naming convention.
I noticed that PGDG will sometimes change the name of some packages in
order to include the version of postgres that they were compiled against
(or maybe that they require at runtime).  An example would be postgis2_95.

For reference, in the EPEL repo, PostGIS does not have the 95 modifier.
Here's a "yum list" result for postgis:
postgis.x86_64                          2.0.7-1.el7                    epel

I wanted to ask if there's a reason that GDAL didn't follow this
convention.  Even though each version of GDAL has a BuildRequires line that
specifies a pgmajorversion build dependency, the result isn't a gdal95 RPM.

Is the reason because there's no runtime dependency on postgres (just a
build one only)?

Also, if I used a version of gdal that was compiled with PostgreSQL 9.2
with my postgis2_95 build, would there be cause for concern?  With the "95"
off of the GDAL package name, it sort of implies that this sort of mixing /
matching would potentially be safe.  I'm guessing that's not the case, but
I figured it's worth asking.

Thank you!

Regards,
  -John Harvey


^ permalink  raw  reply  [nested|flat] 2+ messages in thread

* Re: GDAL package naming question
@ 2016-09-26 10:49  Devrim Gündüz <[email protected]>
  parent: John Harvey <[email protected]>
  0 siblings, 0 replies; 2+ messages in thread

From: Devrim Gündüz @ 2016-09-26 10:49 UTC (permalink / raw)
  To: John Harvey <[email protected]>; pgsql-pkg-yum


Hi John,

On Wed, 2016-08-17 at 13:52 -0400, John Harvey wrote:
> 
> I had a question about the GDAL package naming convention.
> I noticed that PGDG will sometimes change the name of some packages in
> order to include the version of postgres that they were compiled against
> (or maybe that they require at runtime).  An example would be postgis2_95.

Right.

> For reference, in the EPEL repo, PostGIS does not have the 95 modifier.
> Here's a "yum list" result for postgis:
> postgis.x86_64                          2.0.7-1.el7                    epel

Right, they support only one version.

> I wanted to ask if there's a reason that GDAL didn't follow this
> convention.  Even though each version of GDAL has a BuildRequires line that
> specifies a pgmajorversion build dependency, the result isn't a gdal95 RPM.
> 
> Is the reason because there's no runtime dependency on postgres (just a
> build one only)?

Well, I thought about adding suffix to gdal before, but then it might break
other packages that depend on versionless gdal.

Noone actually complained about it so far, so I *assumed* it is working. :-)

> Also, if I used a version of gdal that was compiled with PostgreSQL 9.2
> with my postgis2_95 build, would there be cause for concern?  With the "95"
> off of the GDAL package name, it sort of implies that this sort of mixing /
> matching would potentially be safe.  I'm guessing that's not the case, but
> I figured it's worth asking.

Again, I did not hear any complaints from the field (yet), so... :)

Regards,

-- 
Devrim GÜNDÜZ
EnterpriseDB: http://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
Twitter: @DevrimGunduz , @DevrimGunduzTR


Attachments:

  [application/pgp-signature] signature.asc (819B, 2-signature.asc)
  download

^ permalink  raw  reply  [nested|flat] 2+ messages in thread


end of thread, other threads:[~2016-09-26 10:49 UTC | newest]

Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2016-08-17 17:52 GDAL package naming question John Harvey <[email protected]>
2016-09-26 10:49 ` Devrim Gündüz <[email protected]>

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox