Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ba51F-0002jd-A8 for pgsql-pkg-yum@arkaria.postgresql.org; Wed, 17 Aug 2016 17:52:49 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1ba51E-00045X-SM for pgsql-pkg-yum@arkaria.postgresql.org; Wed, 17 Aug 2016 17:52:48 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ba51E-00045R-Ky for pgsql-pkg-yum@postgresql.org; Wed, 17 Aug 2016 17:52:48 +0000 Received: from mail-oi0-x233.google.com ([2607:f8b0:4003:c06::233]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1ba51B-00035V-43 for pgsql-pkg-yum@postgresql.org; Wed, 17 Aug 2016 17:52:47 +0000 Received: by mail-oi0-x233.google.com with SMTP id l203so147373277oib.1 for ; Wed, 17 Aug 2016 10:52:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=crunchydata-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=ch7X/Huo6EsGVrF0MizvoB+mKNbcMGLqXu0faDp7oi0=; b=a89OxjZAP1u6DMkck8mxo0mfizOpQHtxofvBabmESkTNybLg47tQjxZkTS1ixOv5eT W509Fn5mGuSULHx9e3PP4RkIDyyBDIJSE55p9/VxJPNqc8wIukolSSh3sBfTE/qkE432 R+ee4L4xgGNSPNNwo2PsgmLInl/jso6vun6ptWna7aQaAeuUeAHsl9WOjvnXayF9Vn9a q5xM7DT462AYZEcken5FRc+tbNFVz/uPm8DmMkHVP8AGFAU4Cbdv3RnZ6CKh9FdkxHXp oJJFI0FLTi36+xLkaFhnCdJcMk/v0Uaxpp3/04qkgu1pkZV6tDmFQFUCAhVSXTqXHZ8L k9bA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ch7X/Huo6EsGVrF0MizvoB+mKNbcMGLqXu0faDp7oi0=; b=U3UG/XAm2SJRCsb6NZP5n7sE4A5h9p5mY77l1heAr58vquQC2LGoAp0mbiG+Bp8yXF qbOpPT+t7XoV4bLjehFJfIXC4V7aHtEBjA5+ijOTWi7McTVt6JahlREtZnCqlADVdcQv VAEwiuxKdGRLokX+7ln1bsZg6hyu3w6dxALOKKC1YNghTOM90smcm/ayUXpI9RB0xhfQ mln8K5QInxSr3S26rSDauWvFKYZ92mAr+TM8i0z5mxCk2dRReQxQw7UIuIMaNzivaaxy +czCryBfmJVL5sNYX59ImbAghVF9XL5pRPZNYCFy3G7zyV4m5SsBKT7RUtPMxRXXv0as d65w== X-Gm-Message-State: AEkoousPseI4z9FjIak2LxjPbW3ra07tiZA2Pjkm3rif160xTa13Qe5GGCSgu6GOm+qqmhVQQQgIUpQiGLRLLg== X-Received: by 10.157.29.236 with SMTP id w41mr1658829otw.113.1471456362636; Wed, 17 Aug 2016 10:52:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.68.194 with HTTP; Wed, 17 Aug 2016 10:52:41 -0700 (PDT) From: John Harvey Date: Wed, 17 Aug 2016 13:52:41 -0400 Message-ID: Subject: GDAL package naming question To: pgsql-pkg-yum Content-Type: multipart/alternative; boundary=001a113cf7b0cc3e59053a482191 X-Pg-Spam-Score: -2.6 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-pkg-yum Precedence: bulk Sender: pgsql-pkg-yum-owner@postgresql.org --001a113cf7b0cc3e59053a482191 Content-Type: text/plain; charset=UTF-8 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 --001a113cf7b0cc3e59053a482191 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello folks,

I had a question about the GDAL package na= ming convention.
I noticed that PGDG w= ill sometimes change the name of some packages in order to include the vers= ion of postgres that they were compiled against (or maybe that they require= at runtime).=C2=A0 An example would be=C2=A0postgis2_95.

For reference, in the EPEL repo, PostGIS does no= t have the 95 modifier.
Here's a &= quot;yum list" result for postgis:
postgis.x86_64 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02.0.7-1.el7 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0epel

I wanted to ask if there's a reason that GDAL didn't follo= w this convention.=C2=A0 Even though each version of GDAL has a BuildRequir= es line that specifies a pgmajorversion build dependency, the result isn= 9;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 w= ith PostgreSQL 9.2 with my postgis2_95 build, would there be cause for conc= ern?=C2=A0 With the "95" off of the GDAL package name, it sort of= implies that this sort of mixing / matching would potentially be safe.=C2= =A0 I'm guessing that's not the case, but I figured it's worth = asking.

Thank yo= u!

Regards,
=C2=A0 -John Harvey
--001a113cf7b0cc3e59053a482191--