Versioned mo file installation
One issue with packaged multiple-version installations (practiced by
Debian, Solaris, and soon Fedora?) is that the mo files (translation
files) should be in a fixed location like /usr/share/locale, which does
not allow PostgreSQL-version specific subdirectories.
The Debian packages solve this by appending a version number to the mo
files themselves, as can be seen in this patch:
Solaris packaging is currently looking for a solution, and the Fedora
initiative might as well? So I figured we could adopt something like
the above patch as a built-in solution, as a build option or even by
default.
Comments?
Solaris currently stores messages into separate directories like
/usr/postgres/8.3/share/locale which solves multiversion problem, but it brings
another problem, because gettext on solaris needs extra directory infrastructure.
I think debians patch is good approach.
Zdenek
Peter Eisentraut napsal(a):
Show quoted text
One issue with packaged multiple-version installations (practiced by
Debian, Solaris, and soon Fedora?) is that the mo files (translation
files) should be in a fixed location like /usr/share/locale, which does
not allow PostgreSQL-version specific subdirectories.The Debian packages solve this by appending a version number to the mo
files themselves, as can be seen in this patch:Solaris packaging is currently looking for a solution, and the Fedora
initiative might as well? So I figured we could adopt something like
the above patch as a built-in solution, as a build option or even by
default.Comments?
Peter Eisentraut wrote:
Solaris packaging is currently looking for a solution, and the Fedora
initiative might as well? So I figured we could adopt something like
the above patch as a built-in solution, as a build option or even by
default.
I cannot see the patch right now, but I think this is a good idea in
principle.
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
On Fri, 2008-12-05 at 16:20 +0200, Peter Eisentraut wrote:
Solaris packaging is currently looking for a solution, and the Fedora
initiative might as well? So I figured we could adopt something like
the above patch as a built-in solution, as a build option or even by
default.Comments?
Sounds good to me.
Regards,
--
Devrim GÜNDÜZ , RHCE
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: PL/php, ODBCng - http://www.commandprompt.com/
Peter Eisentraut wrote:
The Debian packages solve this by appending a version number to the mo
files themselves, as can be seen in this patch:
Of course, as is it's not acceptable; the version number should be
obtained from PG_VERSION or some such.
I am not sure the "libpq5" versioning is best; maybe we don't change the
API but we could certainly change error messages between versions. I
think we should keep it as libpq-8.3, like the rest.
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Hi Alvaro,
Alvaro Herrera [2008-12-05 14:06 -0300]:
Of course, as is it's not acceptable; the version number should be
obtained from PG_VERSION or some such.
Right, it has actually been on my long-term wishlist to replace that
patch with an autoconfiscated one with a non-hardcoded version number.
I just didn't do it yet because it was generally rejected when I
proposed it upstream some years ago.
I am not sure the "libpq5" versioning is best; maybe we don't change the
API but we could certainly change error messages between versions. I
think we should keep it as libpq-8.3, like the rest.
Doesn't make much of a difference indeed, I just made it match the
package name. Also, libpq5 built from -8.3 is used with postgresql-8.2
as well.
Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)