Re: packaging Postgres binary dump files
On 20/09/13 17:07, Paul Tagliamonte wrote:
> On Fri, Sep 20, 2013 at 05:04:50PM +0200, Daniel Pocock wrote:
>> On 20/09/13 15:49, Paul Tagliamonte wrote:
>>> On Fri, Sep 20, 2013 at 02:47:39PM +0100, Jonathan Dowland wrote:
>>>> On Fri, Sep 20, 2013 at 12:20:38PM +0200, Paul Wise wrote:
>>>>> It is also impossible to patch the binary format unlike SQL.
>>>> Interesting. For the first time, I've realised there can be a clash between
>>>> "preferred form for modification" and "preferred form for use".
>>> I mean, not really, right?
>>>
>>> If I want to use a .so, I want the ELF, but I want to modify it in C
>>>
>>>
>>> This just means we ship the prefered form for use (this binary kruft)
>>> but ship the preferred form for modification in the source.
>> The rules file could apply changes if required, pg_restore | something |
>> pg_dump again.
>>
>> The current version of the postbooks-schema-* packages are now in
>> collab-maint git. They simply install these files to
>> /usr/share/postbooks-schema but make no attempt to load them into PostgreSQL
>>
>> In this case, it is a client-server solution. There is no guarantee the
>> client code (package: postbooks) runs on the same host as the database
>> (packages postgresql and postbooks-schema-quickstart). Maybe the user
>> even has some Windows clients too. So we have no easy way to
>> synchronize changes to the client package and the database.
>>
>> If somebody wants to create any indexes in the database, details can go
>> in README.Debian. The administrator can then choose how to use it.
>>
>> However, if the package is formally rejected by the FTP masters then I
>> will be happy to change it to ASCII SQL if required.
> Please include the source / preferred form for modification in the
> source, and create this postgres thing from that.
I've now re-created the git repos on alioth and created a new version of
the orig.tar.gz that includes both the file downloaded from upstream and
an ASCII SQL
Only the SQL is shipped in the binary package.
The file from upstream is not distributed in the binary package for now
and we do not try to regenerate it either. The conversion between this
format and ASCII is one way with the pg_restore command. We convert the
file from binary to SQL during the creation of the orig.tar.gz (it is a
repackaged upstream tarball in effect).
To go the other way (from an ASCII SQL into a binary dump file) during
the package build phase, it needs to be loaded into a running PostgreSQL
server and then extracted with pg_dump. I don't think that is a great
build dependency, especially if we want to support things like chroot
builds.
There are two downsides to this approach:
- user doesn't get the benefit of the pg_restore features for selective
restore
- the usage instructions are very slightly different from what upstream
describes, in particular, the SQL is zipped and has to be piped through
zcat when using it
Reply to: