[Pkg-postgresql-public] Bug#868232: lost (unintentionally) unconditional pg_updatedicts on postinst

Christian Ehrhardt christian.ehrhardt at canonical.com
Thu Jul 13 12:05:05 UTC 2017


Package: postgresql-common
Version: 184
Severity: normal

This is suggesting a fix for the recent autopkgtest errors like [1], more
of them at [2].

TL;DR:
- we should add an unconditional pg_updatedicts on "configure" in the
postinst.
- This bug is explaining the details and polling for opinions on adding
that line

Details:

Formerly e.g. version 181 when installing on a clean system created
/var/cache/postgresql:
$ ls -dlaF /var/cache/postgresql
ls: cannot access '/var/cache/postgresql': No such file or directory
$ sudo apt install postgresql-common
[...]
$ ls -dlaF /var/cache/postgresql
drwxr-xr-x 3 root root 4096 Jul 13 07:43 /var/cache/postgresql/


But now e.g. with version 184 it doesn't do that anymore:
$ ls -dlaF /var/cache/postgresql
ls: cannot access '/var/cache/postgresql': No such file or directory
$ sudo apt install postgresql-common
[...]
$ ls -dlaF /var/cache/postgresql
ls: cannot access '/var/cache/postgresql': No such file or directory


The reason is the dropping of the following statement that was considered
to be no more needed:
if dpkg --compare-versions "$2" lt 94; then
    pg_updatedicts || true
fi

I agree version 94 is long ago.
But since then, due to a mistake, this always was an unconditional
pg_updatedicts call on first install.

Quote from dpkg:
"These treat an empty version as earlier than any version: lt le eq ne ge
gt."

Now on a new install of postgresql-common $2 is empty and so this triggered
on first install since version 95.

That in turn might seem unimportant, but affects cases where the first
pg_updatedicts that is executed is under special conditions.
Exactly that happens on the autopkgtests of postgresql-9.6 (or later).
There the test dependencies install postgresql-common, as outlined above
now without calling pg_updatedicts.
Due to that the directory does not exist when the tests themselves call
pg_updatedicts to update the dicts.

But because they do so with a umask o 077
postgresql-common-184/testsuite:
 22 : ${PG_UMASKS="077"} # default umask(s) to try

[...]
169     umask $U
[...]
Finally t/150_tsearch_stemming.t will all pg_updatedicts in that env
But due to the umask it is created as
drwx------ 3 root root 4096 Jul 13 07:43 /var/cache/postgresql/

And that finally lets the test fail with an issue like in [1]
=== Running test 150_tsearch_stemming.t ... ===
[...[
not ok 9 - creating en_US full text search configuration ERROR:  could not
open dictionary file "/usr/share/postgresql/9.6/tsearch_data/en_us.dict":
Permission denied

Ok, long story short - we should make sure the base directory is created
correctly on postinst.
Therefor I suggest really adding an unconditional pg_updatedicts in there.
The postrm already has the matching rm to clean the dir up btw.


[1]:
https://ci.debian.net/data/autopkgtest/unstable/amd64/p/postgresql-9.6/20170713_010956/log.gz
[2]: https://ci.debian.net/packages/p/postgresql-9.6/unstable/amd64/

-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-postgresql-public/attachments/20170713/5248de0b/attachment.html>


More information about the Pkg-postgresql-public mailing list