On systems where /etc/env.d/02locale consists of one-liner like this: LANG=en_US.UTF-8 the pkg_config() function of dev-db/postgresql-server doesn't work. I have no idea why the ebuild want to go through the trouble of file parsing to get the locale. From my experience, initdb would have picked up the system's locale automatically anyway. People who want to set a specific locale would have run initdb manaully, while people who don't care about locale also have to run initdb manually now because the ebuild was trying to be too smart. Reproducible: Always
(In reply to comment #0) > On systems where /etc/env.d/02locale consists of one-liner like this: > > LANG=en_US.UTF-8 > > the pkg_config() function of dev-db/postgresql-server doesn't work. > > I have no idea why the ebuild want to go through the trouble of file parsing to > get the locale. From my experience, initdb would have picked up the system's > locale automatically anyway. > > People who want to set a specific locale would have run initdb manaully, while > people who don't care about locale also have to run initdb manually now because > the ebuild was trying to be too smart. > > Reproducible: Always > Please see bug 233572 as to why the ebuild behaves in the manner it does. Also, for the proposed update to the init and conf, please see bug 311047. New official documentation is currently being worked on to cover this behavior.
Regarding bug 233572, I strongly disagree that having to change /etc/env.d/02locale just for postgresql is "the Gentoo way". The original way of allowing locale (and other options) to be set through PG_INITDB_OPTS environment variable is much cleaner, because this is a setting used by initdb only. Unfortunately, instead of properly fixing bug 233572 to take in the environment variable, you and the maintainer went and put in an over-engineered solution that has no use case. The original fix from Vincent would have been perfect. Anyway, if you think the current ebuild is fine, that's fine for me. I can just rename the locale file to be /etc/env.d/01locale, so that it is safe from being misused by misbehaving ebuild(s). BTW, if you think initdb is having problem selecting a reasonable default locale and encoding (which actually work fine for me), shouldn't you file a bug upstream instead? I thought that's how Gentoo supposed to work.
The ebuild does not misuse 02locale file. The ebuild merely sources (reads) 02locale, but only if PG_INITDB_OPTS is not set in the respective conf, which is sourced first. There are occasions when a user will localize their system after emerging PostgreSQL, and in those cases initdb won't pick up the changes. THis has more to do with the way Gentoo handles things than upstream. The ebuild does utilize the solution from Vincent. It sources the conf file for the PG_INITDB_OPTS variable. The ebuild goes a step further to make sure that PG_INITDB_OPTS is set properly for the locale and encoding.
> The ebuild does not misuse 02locale file. If the ebuild does not misuse the locale file, then why won't it work on a system with one-liner /etc/env.d/02locale like this: LANG=en_US.UTF-8 Each and every part of the system is fine with this /etc/env.d/02locale, except pkg_config() in postgresql ebuild. > There are occasions when a user will localize their system after emerging PostgreSQL, and in those cases initdb won't pick up the changes. THis has more to do with the way Gentoo handles things than upstream. OK, now we are getting into something. I suppose you mean environment.bz2 may contain old locale? If that's the case, then the simplest solution is to make pkg_config() to "eval `locale`", and then just hand off the locale handling to initdb, which will inherit the locale from the environment. What you did with the ebuild was essentially shifting that "inherit the locale from the environment" functionality from initdb into the ebuild itself. Obviously, initdb can do this job better because it has gone through hundreds of revisions.
Ah, eval `locale` doesn't work if the ebuild already inherits from environment.bz2. Unsetting all locale-related environment variables, and then sourcing from /etc/env.d/02locale (or /etc/profile.env) should be sufficient for initdb to work though.
(In reply to comment #5) > Ah, eval `locale` doesn't work if the ebuild already inherits from > environment.bz2. Unsetting all locale-related environment variables, and then > sourcing from /etc/env.d/02locale (or /etc/profile.env) should be sufficient > for initdb to work though. > Yes, but there isn't a one to one relationship here. LANG doesn't correlate to anything that initdb can set. So, you'd just end up with C or POSIX for all of the various LC settings.
> LANG doesn't correlate to anything that initdb can set. So, you'd just end up with C or POSIX for all of the various LC settings Wrong. If only LANG is set and none of the LC_* is set, initdb can pick up the locale from LANG without any problem, whereas the half-baked function in the ebuild can't.
I'll assign the bug to the proper maintainers, but can the reporter please, simply, write a conclusion about this report? Do you propose something? Do you just complain about the current ebuilds behaviour? What exactly do you suggest here?
Comment 4 has a suggestion that doesn't work. Comment 5 has one that should work. My complaint could be harsh, but I did suggest the fix if you read through the comments.
Created attachment 227187 [details, diff] remove artificial intelligence from pkg_config()
Thank you for submitting your suggestion. It is a bit more elegant than the script in there at the moment, so I'll give it a go and see how it works out.
Done.
