Bug 925288 – dev-db/postgresql might want to depend on sys-libs/timezone-data

• Product: Gentoo Linux
• Status: UNCONFIRMED ---

[Description A. Wilcox (awilfox) 2024-02-23 04:20:21 UTC]

musl libc systems don't have timezone-data in their stages (and the handbook, imo somewhat wrongly, implies it doesn't even work on musl?).

PostgreSQL does work, but it is unhappy:

 * Initializing the database ...
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.

The database cluster will be initialized with locale "C.UTF8".
The default text search configuration will be set to "english".

Data page checksums are disabled.

fixing permissions on existing directory /var/lib/postgresql/16/data ... ok
creating subdirectories ... ok
selecting dynamic shared memory implementation ... posix
selecting default max_connections ... 100
selecting default shared_buffers ... 128MB
selecting default time zone ... initdb: warning: could not open directory "/usr/share/zoneinfo": No such file or directory
UTC0
creating configuration files ... ok
running bootstrap script ... 2024-02-23 04:00:24.340 GMT [1575] LOG:  could not open directory "/usr/share/zoneinfo": No such file or directory
ok
performing post-bootstrap initialization ... 2024-02-23 04:00:24.435 GMT [1577] LOG:  could not open directory "/usr/share/zoneinfo": No such file or directory
ok
syncing data to disk ... ok



# rc-service postgresql-16 start
 * Caching service dependencies ... [ ok ]
 * /run/postgresql: creating directory
 * /run/postgresql: correcting owner
 * Starting PostgreSQL 16 ...
2024-02-23 04:11:11.810 GMT [1819] LOG:  could not open directory "/usr/share/zoneinfo": No such file or directory [ ok ]
# 



I can confirm merging sys-libs/timezone-data does silence these warnings, and creating /etc/localtime symlinks does have the intended effect on musl systems as well:

# ln -s /usr/share/zoneinfo/America/Chicago /etc/localtime; date; rm /etc/localtime; date
Thu Feb 22 22:18:52 CST 2024
Fri Feb 23 04:18:52 UTC 2024

I am not 100% sure if all of PostgreSQL's date/time query functions would work properly without timezone-data installed.  If that behaviour would be relevant to this bug, I can try to create a test cluster somewhere and do some digging.

[Comment 1 Aaron W. Swenson 2024-02-28 03:17:22 UTC]

I'm fine with adding timezone-data to the rdepends. There is a small subset of date/time functions that would work without it, but that seems silly since the recommendation for datetime data is to store with timezone info. Weird behavior might arise out of not having it there.