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. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87wqm95f9q....@gkar.ganneff.de
