From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec>, ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: HEAD build failure on win32 mingw |
Date: | 2008-11-21 21:33:47 |
Message-ID: | 18613.1227303227@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> Tom Lane wrote:
>> ... the file
>> that is actually being delivered in snapshots still contains man1/
>> and manl/. So that file needs to be regenerated. Peter?
> Shouldn't it be part of the nightly snapshot creation to make that file?
> In the snapshot I just downloaded its date is yesterday.
The tar file's own date might be yesterday, but its contents are dated
2003-11-02 ... and indeed look to be that old. So something's bollixed
in the snapshot generation process.
Historically the man.tar.gz files were created manually because there
were some manual fixups needed to the generated man files. I'm not sure
what vestiges of that still remain --- Peter's generally been the one to
take care of it. But we definitely aren't shipping a freshly generated
copy in the nightly snapshot right now.
If we do have a fully automated process now, it's probably fair to ask
why there's an internal tarball involved at all, rather than just
shipping the built man1/ and man7/ subdirectories (and likewise for the
html). Double compression of that data isn't going to be helpful.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2008-11-21 21:35:21 | Re: Autoconf, libpq and replacement function |
Previous Message | Bruce Momjian | 2008-11-21 21:33:16 | Re: Cool hack with recursive queries |