Обсуждение: 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)