Re: 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:

http://bazaar.launchpad.net/~pitti/postgresql/debian-8.3/annotate/127?file_id=03gettextdomains.pat-20060925215343-vp3e1xxgtg0tzea6-45

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):
> 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:
>
> http://bazaar.launchpad.net/~pitti/postgresql/debian-8.3/annotate/127?file_id=03gettextdomains.pat-20060925215343-vp3e1xxgtg0tzea6-45
>
>
> 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:

> http://bazaar.launchpad.net/~pitti/postgresql/debian-8.3/annotate/127?file_id=03gettextdomains.pat-20060925215343-vp3e1xxgtg0tzea6-45
>
> 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:
>
> http://bazaar.launchpad.net/~pitti/postgresql/debian-8.3/annotate/127?file_id=03gettextdomains.pat-20060925215343-vp3e1xxgtg0tzea6-45

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)