Обсуждение: Missing directory when building 8.2.3-base
I built the "-base" version of 8.2.3 today, for installation at a company I'm helping out. The build (and later, the installation) gave me an error about a missing directory "test/regress". IIRC I downloaded ftp://ftp.us.postgresql.org/pub/mirrors/postgresql/source/v8.2.3/postgresql-base-8.2.3.tar.bz2 I worked around the problem by creating a directory src/test/regress containing a Makefile with inert "all" and "install" targets. That was enough to get a working installation. Is this a known problem? Is there any test procedure that builds the "base" distribution before release? Jeroen
Jeroen T. Vermeulen wrote: > Is this a known problem? Is there any test procedure that builds the > "base" distribution before release? Most of the core team is convinced that the postgresql-foo tarballs are useless, but Marc insists on keeping them. But since they are nearly useless, no one tests them, so it is not surprising that they don't work. -- Peter Eisentraut http://developer.postgresql.org/~petere/
On Tue, February 13, 2007 01:45, Peter Eisentraut wrote: > Most of the core team is convinced that the postgresql-foo tarballs are > useless, but Marc insists on keeping them. But since they are nearly > useless, no one tests them, so it is not surprising that they don't > work. Well, hurray for Marc! I'm writing from a country where "broadband" is still measured in kilobits per second, and the government censors (and causes the various companies and government monopolies along the way to censor) Internet traffic, keeping the ICT infrastructure slow and unreliable. International bandwidth comes at premium prices for those who can afford serious connections. Much hardware on sale here is either counterfeit or export products that failed quality-control tests or otherwise "fell of the boat." Downloads are sometimes quietly corrupted, without any errors at the TCP level. Long-lived connections often time out. Not having to download half again the size of a "-base" tarball can make a difference in those situations, as can not having to download it all in one single large file. Jeroen
"Jeroen T. Vermeulen" <jtv@xs4all.nl> writes:
> I built the "-base" version of 8.2.3 today, for installation at a company
> I'm helping out.
There is no "-base version". The split tarballs are a convenience for
downloading over slow lines; it is not intended that you can build after
downloading just some of them.
It's been suggested repeatedly that we get rid of the split tarballs
because they confuse people, and hardly anyone these days has a line
slow enough that it's really important to be able to segment the download.
regards, tom lane
Tom Lane wrote: > There is no "-base version". The split tarballs are a convenience > for downloading over slow lines; it is not intended that you can > build after downloading just some of them. It used to be possible to build at least the -base tarball independently. But again, none of this was ever regularly or systematically tested. -- Peter Eisentraut http://developer.postgresql.org/~petere/
Peter Eisentraut wrote:
> Jeroen T. Vermeulen wrote:
>> Is this a known problem? Is there any test procedure that builds the
>> "base" distribution before release?
>
> Most of the core team is convinced that the postgresql-foo tarballs are
> useless, but Marc insists on keeping them. But since they are nearly
> useless, no one tests them, so it is not surprising that they don't
> work.
Why do we keep them again? I can't recall at any point in the life of
CMD us ever using the -foo tarballs. Not to mention they just take up space.
Let's dump them.
Joshua D. Drake
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/
On Feb 12, 5:16 pm, j...@commandprompt.com ("Joshua D. Drake") wrote:
> Peter Eisentraut wrote:
> > Jeroen T. Vermeulen wrote:
> >> Is this a known problem? Is there any test procedure that builds the
> >> "base" distribution before release?
>
> > Most of the core team is convinced that the postgresql-foo tarballs are
> > useless, but Marc insists on keeping them. But since they are nearly
> > useless, no one tests them, so it is not surprising that they don't
> > work.
>
> Why do we keep them again? I can't recall at any point in the life of
> CMD us ever using the -foo tarballs. Not to mention they just take up space.
>
> Let's dump them.
The FreeBSD database/postgres* ports depend on them. Which is probably
why Marc insists on keeping them.
Andrew
Andrew Hammond wrote:
> On Feb 12, 5:16 pm, j...@commandprompt.com ("Joshua D. Drake") wrote:
>
>> Peter Eisentraut wrote:
>>
>>> Jeroen T. Vermeulen wrote:
>>>
>>>> Is this a known problem? Is there any test procedure that builds the
>>>> "base" distribution before release?
>>>>
>>> Most of the core team is convinced that the postgresql-foo tarballs are
>>> useless, but Marc insists on keeping them. But since they are nearly
>>> useless, no one tests them, so it is not surprising that they don't
>>> work.
>>>
>> Why do we keep them again? I can't recall at any point in the life of
>> CMD us ever using the -foo tarballs. Not to mention they just take up space.
>>
>> Let's dump them.
>>
>
> The FreeBSD database/postgres* ports depend on them. Which is probably
> why Marc insists on keeping them.
>
>
Well, I think that's a horrid dependency to have. Other packaging
systems (e.g. the RPM builds) seem quite able to split up a single
unified build into multiple packages - what can't FBSD? What would we do
if some other packaging system wanted to ask us for a different split?
cheers
andrew
Andrew Hammond wrote: > The FreeBSD database/postgres* ports depend on them. Which is > probably why Marc insists on keeping them. I hesitate to believe that seeing that they don't actually work, whereas we have heard no complaints that the FreeBSD ports don't work. -- Peter Eisentraut http://developer.postgresql.org/~petere/
> > The FreeBSD database/postgres* ports depend on them. Which is probably > > why Marc insists on keeping them. > > Well, I think that's a horrid dependency to have. Other packaging > systems (e.g. the RPM builds) seem quite able to split up a single > unified build into multiple packages - what can't FBSD? What would we do > if some other packaging system wanted to ask us for a different split? I am not particularly impressed with the FreeBSD database/postgres* ports. The emphasis on splitting postgres into -server -client and - contrib packages, while in keeping with the rest of the ports collection seems misplaced when you consider that they offer no mechanism (at least of which I am aware) to support multiple versions of the binary. I can't imagine a situation where I would care about having separate packages, aside from being annoyed that some of the more valuable stuff in contrib is not built / installed. Does anyone operate a production environment without at least pgstattuple? On the other hand, every production server I've worked on has had at least 2 binary packages installed and ready for use at all times (the current build and the last production build in case we're forced to roll back). In many cases servers I've worked on have had multiple back-ends running, often with different binaries.
Peter Eisentraut <peter_e@gmx.net> writes:
> Andrew Hammond wrote:
>> The FreeBSD database/postgres* ports depend on them. Which is
>> probably why Marc insists on keeping them.
> I hesitate to believe that seeing that they don't actually work, whereas
> we have heard no complaints that the FreeBSD ports don't work.
I would assume that "depends on" means "they prefer to download all the
smaller tarballs instead of the one big one". But they must be building
with the complete tree in place, so this seems a mighty weak form of
dependency.
regards, tom lane
Peter Eisentraut wrote: > Andrew Hammond wrote: > > The FreeBSD database/postgres* ports depend on them. Which is > > probably why Marc insists on keeping them. > > I hesitate to believe that seeing that they don't actually work, whereas > we have heard no complaints that the FreeBSD ports don't work. Perhaps what it does is install all the split tarballs and build from there, which would be an extremely clever use of split tarballs indeed. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
On 2/13/07, Peter Eisentraut <peter_e@gmx.net> wrote: > Andrew Hammond wrote: > > The FreeBSD database/postgres* ports depend on them. Which is > > probably why Marc insists on keeping them. > > I hesitate to believe that seeing that they don't actually work, whereas > we have heard no complaints that the FreeBSD ports don't work. I am not convinced anyone who is serious about postgresql uses the ports for reasons outlined in a prior post. However, they certainly are used in the ports (FreeBSD 6.2, ports cvsup'd about 2 mins ago): Script started on Tue Feb 13 19:25:28 2007 [root@ahammond /usr/ports/databases/postgresql82-server]# make =========== BACKUP YOUR DATA! ============= As always, backup your data before upgrading. If the upgrade leads to a higherminor revision (e.g. 7.3.x -> 7.4), a dump and restore of all databases is required. This is *NOT* done by the port! Press ctrl-C *now* if you need to pg_dump. =========================================== ===> Found saved configuration for postgresql-server-8.2.3 => postgresql-base-8.2.3.tar.bz2 doesn't seem to exist in /usr/ports/distfiles/postgresql. => Attempting to fetch from ftp://ftp8.us.postgresql.org/postgresql/source/v8.2.3/. postgresql-base-8.2.3.tar.bz2 100% of 8301 kB 619 kBps 00m00s => postgresql-opt-8.2.3.tar.bz2 doesn't seem to exist in /usr/ports/distfiles/postgresql. => Attempting to fetch from ftp://ftp8.us.postgresql.org/postgresql/source/v8.2.3/. postgresql-opt-8.2.3.tar.bz2 100% of 163 kB 171 kBps => postgresql-test-8.2.3.tar.bz2 doesn't seem to exist in /usr/ports/distfiles/postgresql. => Attempting to fetch from ftp://ftp8.us.postgresql.org/postgresql/source/v8.2.3/. postgresql-test-8.2.3.tar.bz2 100% of 962 kB 254 kBps ===> Extracting for postgresql-server-8.2.3 => MD5 Checksum OK for postgresql/postgresql-base-8.2.3.tar.bz2. => SHA256 Checksum OK for postgresql/postgresql-base-8.2.3.tar.bz2. => MD5 Checksum OK for postgresql/postgresql-opt-8.2.3.tar.bz2. => SHA256 Checksum OK for postgresql/postgresql-opt-8.2.3.tar.bz2. => MD5 Checksum OK for postgresql/postgresql-test-8.2.3.tar.bz2. => SHA256 Checksum OK for postgresql/postgresql-test-8.2.3.tar.bz2. -- snip --