help-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How do I correctly relocate PostGIS control files?


From: Gary Johnson
Subject: Re: How do I correctly relocate PostGIS control files?
Date: Tue, 10 Nov 2020 12:45:31 -0500

Carlo Zancanaro <carlo@zancanaro.id.au> writes:

> I didn't respond initially because I don't have any specialist
> knowledge about this. I had some free time today, so I did a bit 
> of an investigation and I think I've figured out what's gone wrong for
> you here.
>
> In your original email you gave this definition for postgresql-13:
>
> ...
>
> However, this is missing one important line from the original
> postgresql definition, which applies a patch to the source:
>
>    (patches (search-patches
>    "postgresql-disable-resolve_symlinks.patch"))
>
> ...
>
> I hope that helps!

***************************************************************************

All hail the mighty Carlo Zancanaro!
Applying that patch to my postgresql-13 package does indeed fix the issue!

***************************************************************************

I have also been digging through the code behind
postgresql-service-type, and I worked out what I'm guessing is the
reason that patch actually works.

In gnu/services/databases.scm, postgresql-service-type is declared and
uses the following function to compute the postgresql package to use for
both its database activation (postgresql-activation) and its shepherd
service (postgresql-shepherd-service):

(define (final-postgresql postgresql extension-packages)
  (if (null? extension-packages)
    postgresql
    (package
      (inherit postgresql)
      (source #f)
      (build-system trivial-build-system)
      (arguments
       `(#:modules ((guix build utils) (guix build union))
         #:builder
         (begin
           (use-modules (guix build utils) (guix build union) (srfi srfi-26))
           (union-build (assoc-ref %outputs "out") (map (lambda (input) (cdr 
input)) %build-inputs))
           #t)))
      (inputs
       `(("postgresql" ,postgresql)
         ,@(map (lambda (extension) (list "extension" extension))
                extension-packages))))))

When extension-packages is (list postgis), then final-postgresql creates
a union-build of both the postgresql and postgis packages, which
essentially just creates a new /gnu/store directory containing the
outputs of both packages.

In exploring my /gnu/store directory, I noticed that even before I
applied Carlo's patch code, there already existed a union-build of my
postgresql-13 and postgis-for-postgresql-13 packages. However, checking
my process table with ps showed that the postgres executable started by
the shepherd service was coming from a /gnu/store directory that ONLY
contained postgresql-13 and NOT from the union-build directory as I
would have expected from the final-postgresql function definition above.

So what gives?

It looks like the individual postgresql-13 and postgis-for-postgresql-13
packages were built correctly and the union-build was also created
correctly (probably either at activation time or at service start time).

HOWEVER, the union-build directory consists primarily of symlinks to the
files in the individual postgresql-13 and postgis-for-postgresql-13
store directories. My guess then is that when the shepherd service fired
up the postgres executable, it was trying to run it from the union-build
directory but after following the symlink, it reported in ps the path to
the target of that symlink rather than the location of the symlink
itself. Then postgres must have taken this symlink target directory as
the actual directory is was being run from, which of course did not
contain any postgis control files.

Long story short, Carlo noticed that the default postgresql package in
gnu/packages/databases.scm, applied this patch to its source code:

postgresql-disable-resolve_symlinks.patch:
***************************************************************************
>From 223c82d1d6ed1f29f26307249827ff679e09c780 Mon Sep 17 00:00:00 2001
From: Julien Lepiller <julien@lepiller.eu>
Subject: [PATCH] disable resolve_symlink

---
 src/common/exec.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/common/exec.c b/src/common/exec.c
index 878fc29..6b3e283 100644
--- a/src/common/exec.c
+++ b/src/common/exec.c
@@ -218,6 +218,8 @@ find_my_exec(const char *argv0, char *retpath)
 static int
 resolve_symlinks(char *path)
 {
+       // On GuixSD we *want* stuff relative to symlinks.
+       return 0;
 #ifdef HAVE_READLINK
        struct stat buf;
        char            orig_wd[MAXPGPATH],
--
2.18.0
***************************************************************************

Based on Julien's code comment, I'm guessing this somehow magically
ensures that the postgres executable is run from the within the
union-build directory where its symlink exists rather than from the
postgresql-13 directory where the symlink is pointing.

So now we appear to have a solution to the missing postgis control file
issue. However, I have a few comments still:

1. The postgresql-11 and postgresql-9.6 packages in
   /gnu/packages/databases.scm are also missing Julien's symlink patch
   and thus do not work in combination with postgis currently.

2. The postgis package in /gnu/packages/geo.scm is currently hard-coded
   to compile against postgresql@10.13. We need some way to tie this to
   a dynamically specified postgresql version or we need another postgis
   package for each version of postgresql it is meant to be paired with.

3. It would be good to add a new version of Postgresql to
   gnu/packages/databases.scm as postgresql-11 is quite out of date at
   this point. Here are my package declarations for postgresql-13 and
   postgis-for-postgresql-13 (although I'm not sure if the arguments
   field is shadowing all the arguments from the inherited postgresql
   package from gnu/packages/database.scm):

(define-public postgresql-13
  (package
   (inherit postgresql)
   (name "postgresql")
   (version "13.0")
   (source (origin
            (method url-fetch)
            (uri (string-append "https://ftp.postgresql.org/pub/source/v";
                                version "/postgresql-" version ".tar.bz2"))
            (sha256
             (base32
              "15i2b7m9a9430idqdgvrcyx66cpxz0v2d81nfqcm8ss3inz51rw0"))
            (patches (search-patches 
"postgresql-disable-resolve_symlinks.patch"))))
   (arguments `(#:tests? #f ,@(package-arguments postgresql)))))

(define-public postgis-for-postgresql-13
  (package
   (inherit postgis)
   (name "postgis")
   (version "3.0.2")
   (inputs
    `(("gdal" ,gdal)
      ("geos" ,geos)
      ("giflib" ,giflib)
      ("json-c" ,json-c)
      ("libjpeg" ,libjpeg-turbo)
      ("libxml2" ,libxml2)
      ("pcre" ,pcre)
      ("postgresql" ,postgresql-13)
      ("proj" ,proj)))))


I'm hoping that Julien or another Guix maintainer can make these changes
to mainline Guix in order to better support geospatial database
programming on our awesome OS.

Happy hacking,
  Gary

-- 
GPG Key ID: 7BC158ED
Use `gpg --search-keys lambdatronic' to find me
Protect yourself from surveillance: https://emailselfdefense.fsf.org
=======================================================================
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

Why is HTML email a security nightmare? See https://useplaintext.email/

Please avoid sending me MS-Office attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html



reply via email to

[Prev in Thread] Current Thread [Next in Thread]