Re: faster testing with symlink installs - Mailing list pgsql-hackers

From Robert Haas
Subject Re: faster testing with symlink installs
Date
Msg-id CA+TgmoY8X30MkH0Df0GMbM=ZMvdEJY_-n_zJHkZiDf5Pnib42w@mail.gmail.com
Whole thread Raw
In response to Re: faster testing with symlink installs  (Michael Paquier <michael@paquier.xyz>)
Responses Re: faster testing with symlink installs  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
On Wed, Mar 21, 2018 at 11:43 PM, Michael Paquier <michael@paquier.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


pgsql-hackers by date:

Previous
From: John Naylor
Date:
Subject: Re: WIP: a way forward on bootstrap data
Next
From: John Naylor
Date:
Subject: Re: WIP: a way forward on bootstrap data