Re: moving from contrib to bin - Mailing list pgsql-hackers

From Tom Lane
Subject Re: moving from contrib to bin
Date
Msg-id 16234.1418397174@sss.pgh.pa.us
Whole thread Raw
In response to Re: moving from contrib to bin  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Responses Re: moving from contrib to bin  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
Heikki Linnakangas <hlinnakangas@vmware.com> writes:
> On 12/12/2014 03:07 PM, Peter Eisentraut wrote:
>> On 12/9/14 4:10 PM, Alvaro Herrera wrote:
>>> Maybe it makes sense to have a distinction between client programs and
>>> server programs.  Can we have src/sbin/ and move stuff that involves the
>>> server side in there?  I think that'd be pg_xlogdump, pg_archivecleanup,
>>> pg_upgrade, pg_test_timing, pg_test_fsync.  (If we were feeling bold we
>>> could also move pg_resetxlog, pg_controldata and initdb there.)

>> I was thinking about that.  What do others think?

> Sounds good. We already separate server and client programs in the docs, 
> and packagers put them in different packages too. This should make 
> packagers' life a little bit easier in the long run.

I'm pretty much -1 on relocating anything that's under src/bin already.
The history mess and back-patching pain would outweigh any notional
cleanliness --- and AFAICS it's entirely notional.  As an ex-packager
I can tell you that where stuff sits in the source tree makes precisely
*zero* difference to a packager.  She's going to do "make install-world"
and then her package recipe will list out which files in the install tree
go into which sub-package.  Perhaps it would get clearer to packagers if
we also installed stuff into $INSTALLDIR/sbin, but I doubt that such a
change is going to fly with anyone else.  The bin vs sbin distinction
is not universal.
        regards, tom lane



pgsql-hackers by date:

Previous
From: David Fetter
Date:
Subject: Re: Commitfest problems
Next
From: Tom Lane
Date:
Subject: Re: moving from contrib to bin