Re: packaging Postgres binary dump files

[Joerg Jaspert <joerg@debian.org>]

On 13340 March 1977, Daniel Pocock wrote:
>>> 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.

I think this is similar to other cases that came up in the past. The
preferred form for modification isn't what is shipped and probably best
to use / used by default from upstream and it's not easy to regenerate
it at build time. The preferred form of modification is a running
database and SQL commands issued to it with whatever interface.

So what you should ship in the source is the file from upstream plus the
SQL to generate it. Ideally you would now build-depend on a running
postgres server, but everyone could understand the armada of black
helicopters that buildd admins will send your way for this.  I would
even lend a chainsaw or two :)

So this falls under the: "Not easy to regenerate" category. Which means
that, ohwell, ship the upstream file - or one you generated yourself
from the SQL, and don't rebuild it on buildds.
BUT *you* *must* make entirely sure that what is shipped corresponds with
the source AKA the SQL file. (And document it in README.source please)
And double bonus points if there is an easy accessible way of getting
from SQL to binary file, say debian/rules rebuild or so. With the
implication that the user has to have a postgres ready for it to load and
dump from. Or so.

-- 
bye, Joerg
Marge, it takes two to lie. One to lie and one to listen.