Re: faster testing with symlink installs

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: faster testing with symlink installs
Date: 2018-03-22 15:07:48
Message-ID: CA+TgmoY8X30MkH0Df0GMbM=ZMvdEJY_-n_zJHkZiDf5Pnib42w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Mar 21, 2018 at 11:43 PM, Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> On Wed, Mar 07, 2018 at 05:06:59PM -0500, Robert Haas wrote:
>> TBH I find that Homebrew example pretty odd. I would understand
>> installing each major release in a version directory, but putting
>> every point release in a different versioned directory seems like a
>> bad plan.
>
> That's a project policy on their side. The version of all components is
> kept around this way to give users the easier possibility to link or use
> back a previous version if a component update does wrong. There are
> advantages to such models as well for projects which care a lot about
> some precise compatibility that some upstream maintainer overlooked,
> while not having to patch an existing instance to filter out only a set
> of components.

Well, under that definition, the behavior Peter is complaining about
upthread is a feature, not a bug. If you want a separate install of
PostgreSQL for every minor release, you should have a separate version
of each other piece of software you build against it. Or so it seems
to me, anyway.

I suppose we could provide a build-time option to change this behavior.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message John Naylor 2018-03-22 15:11:33 Re: WIP: a way forward on bootstrap data
Previous Message John Naylor 2018-03-22 15:02:56 Re: WIP: a way forward on bootstrap data