Thread: Add PG version number to NLS files
I have developed the following patch which adds PG_VERSION to the end of
language-specific file names. I used it for libpq too, rather than the
SONAME, because the language strings might change between versions while
the API/SONAME might not.
Would someone who uses NLS please test this? Thanks.
---------------------------------------------------------------------------
Bruce Momjian wrote:
>
> Is this a direction we want to explore --- using the SONAME as part of
> the translation domain?
>
> ---------------------------------------------------------------------------
>
> Martin Pitt wrote:
> -- Start of PGP signed section.
> > Hi!
> >
> > Bruce Momjian [2005-02-09 18:05 -0500]:
> > > > However, I just stumbled across another problem: libpq3 and the new
> > > > libpq4 use the same translation domain "libpq4", thus they cannot be
> > > > installed in parallel. Can you please change the domain to "libpq4" as
> > > > well? This should generally be done anyway, but at least we can live
> > > > with one breakage of this rule (for libpq3), so that we don't need to
> > > > mess with the old libpq3 package.
> > >
> > > Uh, what is the translation domain?
> >
> > In short, that is the unique name for a bunch of translations for a
> > particular application or group of related applications. The key point
> > is that the name of the file in
> > /usr/share/locale/<LOCALE>/LC_MESSAGES/<DOMAIN>.mo and the call
> >
> > bindtextdomain ("<DOMAIN>", NULL)
> >
> > must use the same <DOMAIN> so that libintl can find the mo file.
> > However, that means that all applications that are installed in
> > parallel need a distinct domain. Since the whole point of SONAMes is
> > to allow several different library API versions to be installed in
> > parallel, every library API (i. e. SONAME) should have an unique
> > domain, which can be achieved easiest by just appending the SONAME to
> > the translation domain.
> >
> > In my test packages I used the following patch:
> >
> > diff -ruN postgresql-8.0.1-old/src/interfaces/libpq/fe-misc.c postgresql-8.0.1/src/interfaces/libpq/fe-misc.c
> > --- postgresql-8.0.1-old/src/interfaces/libpq/fe-misc.c 2004-12-31 23:03:50.000000000 +0100
> > +++ postgresql-8.0.1/src/interfaces/libpq/fe-misc.c 2005-02-07 22:55:13.177419296 +0100
> > @@ -1133,7 +1133,7 @@
> > {
> > already_bound = 1;
> > /* No relocatable lookup here because the binary could be anywhere */
> > - bindtextdomain("libpq", getenv("PGLOCALEDIR") ? getenv("PGLOCALEDIR") : LOCALEDIR);
> > + bindtextdomain("libpq4", getenv("PGLOCALEDIR") ? getenv("PGLOCALEDIR") : LOCALEDIR);
> > }
> >
> > return dgettext("libpq", msgid);
> > diff -ruN postgresql-8.0.1-old/src/interfaces/libpq/nls.mk postgresql-8.0.1/src/interfaces/libpq/nls.mk
> > --- postgresql-8.0.1-old/src/interfaces/libpq/nls.mk 2005-01-14 09:57:06.000000000 +0100
> > +++ postgresql-8.0.1/src/interfaces/libpq/nls.mk 2005-02-07 22:54:54.770217616 +0100
> > @@ -1,5 +1,5 @@
> > # $PostgreSQL: pgsql/src/interfaces/libpq/nls.mk,v 1.20 2005/01/14 08:57:06 petere Exp $
> > -CATALOG_NAME := libpq
> > +CATALOG_NAME := libpq4
> > AVAIL_LANGUAGES := af cs de es fr hr it ko nb pl pt_BR ru sk sl sv tr zh_CN zh_TW
> > GETTEXT_FILES := fe-auth.c fe-connect.c fe-exec.c fe-lobj.c fe-misc.c fe-protocol2.c fe-protocol3.c fe-secure.c
> > GETTEXT_TRIGGERS:= libpq_gettext pqInternalNotice:2
> >
> > Compared to the SONAME, changing the translation domain is relatively
> > uncritical, so if you don't want to change this upstream, I can
> > maintain this patch for Debian/Ubuntu. However, I heard that some RPM
> > guys plan a infrastructure similar to mine, and at that point they
> > will have precisely the same problems :-)
> >
> > Thanks for considering and have a nice day!
> >
> > Martin
> > --
> > Martin Pitt http://www.piware.de
> > Ubuntu Developer http://www.ubuntulinux.org
> > Debian GNU/Linux Developer http://www.debian.org
> -- End of PGP section, PGP failed!
>
> --
> Bruce Momjian | http://candle.pha.pa.us
> pgman@candle.pha.pa.us | (610) 359-1001
> + If your life is a hard drive, | 13 Roberts Road
> + Christ can be your backup. | Newtown Square, Pennsylvania 19073
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
>
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
Index: src/nls-global.mk
===================================================================
RCS file: /cvsroot/pgsql/src/nls-global.mk,v
retrieving revision 1.10
diff -c -c -r1.10 nls-global.mk
*** src/nls-global.mk 1 Jun 2004 03:32:28 -0000 1.10
--- src/nls-global.mk 15 Jun 2005 03:11:49 -0000
***************
*** 39,44 ****
--- 39,45 ----
XGETTEXT += --foreign-user -ctranslator
endif
+ CATALOG_NAME_VER=$(CATALOG_NAME).$(VERSION)
all-po: $(MO_FILES)
***************
*** 47,56 ****
ifdef XGETTEXT
ifeq ($(word 1,$(GETTEXT_FILES)),+)
! po/$(CATALOG_NAME).pot: $(word 2, $(GETTEXT_FILES))
$(XGETTEXT) -D $(srcdir) -n $(addprefix -k, $(GETTEXT_TRIGGERS)) -f $<
else
! po/$(CATALOG_NAME).pot: $(GETTEXT_FILES)
# Change to srcdir explicitly, don't rely on $^. That way we get
# consistent #: file references in the po files.
$(XGETTEXT) -D $(srcdir) -n $(addprefix -k, $(GETTEXT_TRIGGERS)) $(GETTEXT_FILES)
--- 48,57 ----
ifdef XGETTEXT
ifeq ($(word 1,$(GETTEXT_FILES)),+)
! po/$(CATALOG_NAME_VER).pot: $(word 2, $(GETTEXT_FILES))
$(XGETTEXT) -D $(srcdir) -n $(addprefix -k, $(GETTEXT_TRIGGERS)) -f $<
else
! po/$(CATALOG_NAME_VER).pot: $(GETTEXT_FILES)
# Change to srcdir explicitly, don't rely on $^. That way we get
# consistent #: file references in the po files.
$(XGETTEXT) -D $(srcdir) -n $(addprefix -k, $(GETTEXT_TRIGGERS)) $(GETTEXT_FILES)
***************
*** 65,71 ****
install-po: all-po installdirs-po
ifneq (,$(LANGUAGES))
for lang in $(LANGUAGES); do \
! $(INSTALL_DATA) po/$$lang.mo $(DESTDIR)$(localedir)/$$lang/LC_MESSAGES/$(CATALOG_NAME).mo || exit 1; \
done
endif
--- 66,72 ----
install-po: all-po installdirs-po
ifneq (,$(LANGUAGES))
for lang in $(LANGUAGES); do \
! $(INSTALL_DATA) po/$$lang.mo $(DESTDIR)$(localedir)/$$lang/LC_MESSAGES/$(CATALOG_NAME_VER).mo || exit 1; \
done
endif
***************
*** 73,85 ****
$(mkinstalldirs) $(foreach lang, $(LANGUAGES), $(DESTDIR)$(localedir)/$(lang)/LC_MESSAGES)
uninstall-po:
! rm -f $(foreach lang, $(LANGUAGES), $(DESTDIR)$(localedir)/$(lang)/LC_MESSAGES/$(CATALOG_NAME).mo)
clean-po:
rm -f $(MO_FILES)
@rm -f $(addsuffix .old, $(PO_FILES))
! rm -f po/$(CATALOG_NAME).pot
maintainer-check-po: $(PO_FILES)
--- 74,86 ----
$(mkinstalldirs) $(foreach lang, $(LANGUAGES), $(DESTDIR)$(localedir)/$(lang)/LC_MESSAGES)
uninstall-po:
! rm -f $(foreach lang, $(LANGUAGES), $(DESTDIR)$(localedir)/$(lang)/LC_MESSAGES/$(CATALOG_NAME_VER).mo)
clean-po:
rm -f $(MO_FILES)
@rm -f $(addsuffix .old, $(PO_FILES))
! rm -f po/$(CATALOG_NAME_VER).pot
maintainer-check-po: $(PO_FILES)
***************
*** 88,97 ****
done
! init-po: po/$(CATALOG_NAME).pot
! update-po: po/$(CATALOG_NAME).pot
ifdef MSGMERGE
@for lang in $(LANGUAGES); do \
echo "merging $$lang:"; \
--- 89,98 ----
done
! init-po: po/$(CATALOG_NAME_VER).pot
! update-po: po/$(CATALOG_NAME_VER).pot
ifdef MSGMERGE
@for lang in $(LANGUAGES); do \
echo "merging $$lang:"; \
Index: src/interfaces/libpq/fe-misc.c
===================================================================
RCS file: /cvsroot/pgsql/src/interfaces/libpq/fe-misc.c,v
retrieving revision 1.114
diff -c -c -r1.114 fe-misc.c
*** src/interfaces/libpq/fe-misc.c 12 Jun 2005 00:00:21 -0000 1.114
--- src/interfaces/libpq/fe-misc.c 15 Jun 2005 03:11:52 -0000
***************
*** 1134,1140 ****
{
already_bound = 1;
/* No relocatable lookup here because the binary could be anywhere */
! bindtextdomain("libpq", getenv("PGLOCALEDIR") ? getenv("PGLOCALEDIR") : LOCALEDIR);
}
return dgettext("libpq", msgid);
--- 1134,1140 ----
{
already_bound = 1;
/* No relocatable lookup here because the binary could be anywhere */
! bindtextdomain("libpq" PG_VERSION, getenv("PGLOCALEDIR") ? getenv("PGLOCALEDIR") : LOCALEDIR);
}
return dgettext("libpq", msgid);
Index: src/port/path.c
===================================================================
RCS file: /cvsroot/pgsql/src/port/path.c,v
retrieving revision 1.51
diff -c -c -r1.51 path.c
*** src/port/path.c 26 Jan 2005 19:24:03 -0000 1.51
--- src/port/path.c 15 Jun 2005 03:11:53 -0000
***************
*** 507,513 ****
void
set_pglocale_pgservice(const char *argv0, const char *app)
{
! char path[MAXPGPATH];
char my_exec_path[MAXPGPATH];
char env_path[MAXPGPATH + sizeof("PGSYSCONFDIR=")]; /* longer than
* PGLOCALEDIR */
--- 507,514 ----
void
set_pglocale_pgservice(const char *argv0, const char *app)
{
! char path[MAXPGPATH],
! app_with_version[MAXPGPATH + sizeof(PG_VERSION) - 1];
char my_exec_path[MAXPGPATH];
char env_path[MAXPGPATH + sizeof("PGSYSCONFDIR=")]; /* longer than
* PGLOCALEDIR */
***************
*** 521,527 ****
#ifdef ENABLE_NLS
get_locale_path(my_exec_path, path);
! bindtextdomain(app, path);
textdomain(app);
if (getenv("PGLOCALEDIR") == NULL)
--- 522,530 ----
#ifdef ENABLE_NLS
get_locale_path(my_exec_path, path);
! StrNCpy(app_with_version, app, MAXPGPATH + sizeof(PG_VERSION) - 1);
! strncat(app_with_version, PG_VERSION, MAXPGPATH + sizeof(PG_VERSION) - 2);
! bindtextdomain(app_with_version, path);
textdomain(app);
if (getenv("PGLOCALEDIR") == NULL)
Bruce Momjian wrote: > I have developed the following patch which adds PG_VERSION to the end > of language-specific file names. In my mind, that would only make sense if we added the version number to all program binaries as well (which we do not, of course). Otherwise, what's the point? -- Peter Eisentraut http://developer.postgresql.org/~petere/
Peter Eisentraut wrote: > Bruce Momjian wrote: > > I have developed the following patch which adds PG_VERSION to the end > > of language-specific file names. > > In my mind, that would only make sense if we added the version number to > all program binaries as well (which we do not, of course). Otherwise, > what's the point? The 'bind' calles in the binaries are going to look for the proper version. Does that help, or is libpq the only thing we need to handle? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian wrote: > The 'bind' calles in the binaries are going to look for the proper > version. Does that help, or is libpq the only thing we need to > handle? Shared libraries have their version number embedded in the file name for the explicit purpose of installing more than one version side by side. Therefore, the PO files also need to make arrangements for side by side installation. No such promises are made for non-library files. -- Peter Eisentraut http://developer.postgresql.org/~petere/
Peter Eisentraut wrote: > Bruce Momjian wrote: > > The 'bind' calles in the binaries are going to look for the proper > > version. Does that help, or is libpq the only thing we need to > > handle? > > Shared libraries have their version number embedded in the file name for > the explicit purpose of installing more than one version side by side. > Therefore, the PO files also need to make arrangements for side by side > installation. No such promises are made for non-library files. OK, seems we need examples of how our current setup fails, both for libpq and binaries. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Hi! Bruce Momjian [2005-06-15 15:26 -0400]: > Peter Eisentraut wrote: > > Bruce Momjian wrote: > > > The 'bind' calles in the binaries are going to look for the proper > > > version. Does that help, or is libpq the only thing we need to > > > handle? > > > > Shared libraries have their version number embedded in the file name for > > the explicit purpose of installing more than one version side by side. > > Therefore, the PO files also need to make arrangements for side by side > > installation. No such promises are made for non-library files. > > OK, seems we need examples of how our current setup fails, both for > libpq and binaries. Debian's and Ubuntu's packages currently look like this (binary -> translation domain): /usr/lib/libpq3.so: libpq3 /usr/lib/libpq4.so: libpq4 /usr/lib/postgresql/7.4/bin/postmaster: postgres-7.4 /usr/lib/postgresql/8.0/bin/postmaster: postgres-8.0 /usr/lib/postgresql/7.4/bin/psql: psql-7.4 /usr/lib/postgresql/8.0/bin/psql: psql-8.0 [similar for all other client binaries) Without my domain patches, i. e. with upstream's scheme it would look like: /usr/lib/libpq3.so: libpq /usr/lib/libpq4.so: libpq /usr/lib/postgresql/7.4/bin/postmaster: postgres /usr/lib/postgresql/8.0/bin/postmaster: postgres As you see, there is a conflict, so to be able to install both pacakges at the same time, one translation version had to be picked and stuffed into a separate -translations package, which both versions depend on. That's ugly and would cause one version to have some missing translations, therefore I patched the domains to be version-specific. I do think that adopting my scheme at least for libpq really makes sense. Adopting it for the binaries would not do any harm, but it might not be conformant to your packaging policy, which I don't really know. The clashing domains are the only things that prevents the parallel installation of different major versions, so the question whether or not you want to adopt it mainly boils down to whether you want to support parallel server installations. I am grateful that you did the SONAME change upstream, that relieved Debian and probably other vendors of much pain. OTOH, the Debian specific translation domain changes are really simple and don't impose a significant maintenance overhead, so there is no urgency at all. Thanks and have a nice day! Martin -- Martin Pitt http://www.piware.de Ubuntu Developer http://www.ubuntu.com Debian Developer http://www.debian.org
Attachment
Martin Pitt wrote: > /usr/lib/libpq3.so: libpq3 > /usr/lib/libpq4.so: libpq4 > /usr/lib/postgresql/7.4/bin/postmaster: postgres-7.4 > /usr/lib/postgresql/8.0/bin/postmaster: postgres-8.0 > /usr/lib/postgresql/7.4/bin/psql: psql-7.4 > /usr/lib/postgresql/8.0/bin/psql: psql-8.0 > [similar for all other client binaries) > > Without my domain patches, i. e. with upstream's scheme it would look > like: > > /usr/lib/libpq3.so: libpq > /usr/lib/libpq4.so: libpq > /usr/lib/postgresql/7.4/bin/postmaster: postgres > /usr/lib/postgresql/8.0/bin/postmaster: postgres > > As you see, there is a conflict, so to be able to install both > pacakges at the same time, one translation version had to be picked > and stuffed into a separate -translations package, which both versions > depend on. That's ugly and would cause one version to have some > missing translations, therefore I patched the domains to be > version-specific. > > I do think that adopting my scheme at least for libpq really makes > sense. Adopting it for the binaries would not do any harm, but it > might not be conformant to your packaging policy, which I don't really > know. The clashing domains are the only things that prevents the > parallel installation of different major versions, so the question > whether or not you want to adopt it mainly boils down to whether you > want to support parallel server installations. > > I am grateful that you did the SONAME change upstream, that relieved > Debian and probably other vendors of much pain. OTOH, the Debian > specific translation domain changes are really simple and don't impose > a significant maintenance overhead, so there is no urgency at all. We absolutely want to support multiple installed versions of PostgreSQL. In my understanding, it isn't just libpq that depends on version-specific translation files, but all binaries that have translations. Also, it is possible for the SONAME not to change between major versions (if the libpq API remains unchanged), but for the translations to change. For this reason, I think we should add the major number to all bindtextdomain() calls, as is done in the attached patch. Is this conclusion correct? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 Index: src/nls-global.mk =================================================================== RCS file: /cvsroot/pgsql/src/nls-global.mk,v retrieving revision 1.10 diff -c -c -r1.10 nls-global.mk *** src/nls-global.mk 1 Jun 2004 03:32:28 -0000 1.10 --- src/nls-global.mk 15 Jun 2005 03:11:49 -0000 *************** *** 39,44 **** --- 39,45 ---- XGETTEXT += --foreign-user -ctranslator endif + CATALOG_NAME_VER=$(CATALOG_NAME).$(VERSION) all-po: $(MO_FILES) *************** *** 47,56 **** ifdef XGETTEXT ifeq ($(word 1,$(GETTEXT_FILES)),+) ! po/$(CATALOG_NAME).pot: $(word 2, $(GETTEXT_FILES)) $(XGETTEXT) -D $(srcdir) -n $(addprefix -k, $(GETTEXT_TRIGGERS)) -f $< else ! po/$(CATALOG_NAME).pot: $(GETTEXT_FILES) # Change to srcdir explicitly, don't rely on $^. That way we get # consistent #: file references in the po files. $(XGETTEXT) -D $(srcdir) -n $(addprefix -k, $(GETTEXT_TRIGGERS)) $(GETTEXT_FILES) --- 48,57 ---- ifdef XGETTEXT ifeq ($(word 1,$(GETTEXT_FILES)),+) ! po/$(CATALOG_NAME_VER).pot: $(word 2, $(GETTEXT_FILES)) $(XGETTEXT) -D $(srcdir) -n $(addprefix -k, $(GETTEXT_TRIGGERS)) -f $< else ! po/$(CATALOG_NAME_VER).pot: $(GETTEXT_FILES) # Change to srcdir explicitly, don't rely on $^. That way we get # consistent #: file references in the po files. $(XGETTEXT) -D $(srcdir) -n $(addprefix -k, $(GETTEXT_TRIGGERS)) $(GETTEXT_FILES) *************** *** 65,71 **** install-po: all-po installdirs-po ifneq (,$(LANGUAGES)) for lang in $(LANGUAGES); do \ ! $(INSTALL_DATA) po/$$lang.mo $(DESTDIR)$(localedir)/$$lang/LC_MESSAGES/$(CATALOG_NAME).mo || exit 1; \ done endif --- 66,72 ---- install-po: all-po installdirs-po ifneq (,$(LANGUAGES)) for lang in $(LANGUAGES); do \ ! $(INSTALL_DATA) po/$$lang.mo $(DESTDIR)$(localedir)/$$lang/LC_MESSAGES/$(CATALOG_NAME_VER).mo || exit 1; \ done endif *************** *** 73,85 **** $(mkinstalldirs) $(foreach lang, $(LANGUAGES), $(DESTDIR)$(localedir)/$(lang)/LC_MESSAGES) uninstall-po: ! rm -f $(foreach lang, $(LANGUAGES), $(DESTDIR)$(localedir)/$(lang)/LC_MESSAGES/$(CATALOG_NAME).mo) clean-po: rm -f $(MO_FILES) @rm -f $(addsuffix .old, $(PO_FILES)) ! rm -f po/$(CATALOG_NAME).pot maintainer-check-po: $(PO_FILES) --- 74,86 ---- $(mkinstalldirs) $(foreach lang, $(LANGUAGES), $(DESTDIR)$(localedir)/$(lang)/LC_MESSAGES) uninstall-po: ! rm -f $(foreach lang, $(LANGUAGES), $(DESTDIR)$(localedir)/$(lang)/LC_MESSAGES/$(CATALOG_NAME_VER).mo) clean-po: rm -f $(MO_FILES) @rm -f $(addsuffix .old, $(PO_FILES)) ! rm -f po/$(CATALOG_NAME_VER).pot maintainer-check-po: $(PO_FILES) *************** *** 88,97 **** done ! init-po: po/$(CATALOG_NAME).pot ! update-po: po/$(CATALOG_NAME).pot ifdef MSGMERGE @for lang in $(LANGUAGES); do \ echo "merging $$lang:"; \ --- 89,98 ---- done ! init-po: po/$(CATALOG_NAME_VER).pot ! update-po: po/$(CATALOG_NAME_VER).pot ifdef MSGMERGE @for lang in $(LANGUAGES); do \ echo "merging $$lang:"; \ Index: src/interfaces/libpq/fe-misc.c =================================================================== RCS file: /cvsroot/pgsql/src/interfaces/libpq/fe-misc.c,v retrieving revision 1.114 diff -c -c -r1.114 fe-misc.c *** src/interfaces/libpq/fe-misc.c 12 Jun 2005 00:00:21 -0000 1.114 --- src/interfaces/libpq/fe-misc.c 15 Jun 2005 03:11:52 -0000 *************** *** 1134,1140 **** { already_bound = 1; /* No relocatable lookup here because the binary could be anywhere */ ! bindtextdomain("libpq", getenv("PGLOCALEDIR") ? getenv("PGLOCALEDIR") : LOCALEDIR); } return dgettext("libpq", msgid); --- 1134,1140 ---- { already_bound = 1; /* No relocatable lookup here because the binary could be anywhere */ ! bindtextdomain("libpq" PG_VERSION, getenv("PGLOCALEDIR") ? getenv("PGLOCALEDIR") : LOCALEDIR); } return dgettext("libpq", msgid); Index: src/port/path.c =================================================================== RCS file: /cvsroot/pgsql/src/port/path.c,v retrieving revision 1.51 diff -c -c -r1.51 path.c *** src/port/path.c 26 Jan 2005 19:24:03 -0000 1.51 --- src/port/path.c 15 Jun 2005 03:11:53 -0000 *************** *** 507,513 **** void set_pglocale_pgservice(const char *argv0, const char *app) { ! char path[MAXPGPATH]; char my_exec_path[MAXPGPATH]; char env_path[MAXPGPATH + sizeof("PGSYSCONFDIR=")]; /* longer than * PGLOCALEDIR */ --- 507,514 ---- void set_pglocale_pgservice(const char *argv0, const char *app) { ! char path[MAXPGPATH], ! app_with_version[MAXPGPATH + sizeof(PG_VERSION) - 1]; char my_exec_path[MAXPGPATH]; char env_path[MAXPGPATH + sizeof("PGSYSCONFDIR=")]; /* longer than * PGLOCALEDIR */ *************** *** 521,527 **** #ifdef ENABLE_NLS get_locale_path(my_exec_path, path); ! bindtextdomain(app, path); textdomain(app); if (getenv("PGLOCALEDIR") == NULL) --- 522,530 ---- #ifdef ENABLE_NLS get_locale_path(my_exec_path, path); ! StrNCpy(app_with_version, app, MAXPGPATH + sizeof(PG_VERSION) - 1); ! strncat(app_with_version, PG_VERSION, MAXPGPATH + sizeof(PG_VERSION) - 2); ! bindtextdomain(app_with_version, path); textdomain(app); if (getenv("PGLOCALEDIR") == NULL)
Am Samstag, 25. Juni 2005 04:24 schrieb Bruce Momjian: > We absolutely want to support multiple installed versions of PostgreSQL. But we don't support installing multiple versions on top of each other, which is the only scenario where this patch would be useful.
Peter Eisentraut <peter_e@gmx.net> writes:
> Am Samstag, 25. Juni 2005 04:24 schrieb Bruce Momjian:
>> We absolutely want to support multiple installed versions of PostgreSQL.
> But we don't support installing multiple versions on top of each other, which
> is the only scenario where this patch would be useful.
I agree with Peter. AFAICS, the binaries go into $prefix/bin and the
NLS files go into $prefix/share/locale, so there is no more nor less
conflict among different versions' NLS files than their executables.
In both cases the only supported way to have multiple installations
at once is to use different install prefixes. So why complicate matters
like this?
regards, tom lane
Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
> > Am Samstag, 25. Juni 2005 04:24 schrieb Bruce Momjian:
> >> We absolutely want to support multiple installed versions of PostgreSQL.
>
> > But we don't support installing multiple versions on top of each other, which
> > is the only scenario where this patch would be useful.
>
> I agree with Peter. AFAICS, the binaries go into $prefix/bin and the
> NLS files go into $prefix/share/locale, so there is no more nor less
> conflict among different versions' NLS files than their executables.
> In both cases the only supported way to have multiple installations
> at once is to use different install prefixes. So why complicate matters
> like this?
OK. I guess I am confused.
Right now bindtextdomain() just calls something like
bindtextdomain("libpq"), etc. How does it know to use the proper
share/locale? And is bindtextdomain("psql") different?
I am just trying to understand how things work.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
Martin Pitt wrote:
> Hi!
>
> Peter Eisentraut [2005-06-25 11:29 +0200]:
> > Am Samstag, 25. Juni 2005 04:24 schrieb Bruce Momjian:
> > > We absolutely want to support multiple installed versions of PostgreSQL.
> >
> > But we don't support installing multiple versions on top of each other, which
> > is the only scenario where this patch would be useful.
>
> It's not "on top of each other", but side-by-side as Bruce says. The
> single clusters and their postmaster do not influence each other in
> Debian.
I have looked now at the bindtextdomain() code in current CVS and 8.0.X.
We basically have only two bindtextdomain() calls. libpq has this code:
bindtextdomain("libpq", getenv("PGLOCALEDIR") ? getenv("PGLOCALEDIR") : LOCALEDIR);
It basically uses either the environment variable PGLOCALEDIR, or the
hard-coded compile-time LOCALEDIR value. I don't see how adding a
version number to the "libpq" string would help unles PGLOCALEDIR points
to a directory that has both libpq-7.4 and libpq-8.0 directories with
translations, and I didn't see your setup using that.
Our applications call set_pglocale_pgservice(), which makes two
bindtextdomain() calls. It calls set_pglocale_pgservice(), like this:
set_pglocale_pgservice(argv[0], "psql");
The locale files for the application are found relative to the directory
containing the binary. It also sets the environment variable
PGLOCALEDIR so libpq can find its local files.
Based on this analsys, I don't understand what adding the PostgreSQL
version number does for us.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
Hi! Peter Eisentraut [2005-06-25 11:29 +0200]: > Am Samstag, 25. Juni 2005 04:24 schrieb Bruce Momjian: > > We absolutely want to support multiple installed versions of PostgreSQL. > > But we don't support installing multiple versions on top of each other, which > is the only scenario where this patch would be useful. It's not "on top of each other", but side-by-side as Bruce says. The single clusters and their postmaster do not influence each other in Debian. Martin -- Martin Pitt http://www.piware.de Ubuntu Developer http://www.ubuntulinux.org Debian Developer http://www.debian.org