On 2014-12-12 11:27:01 -0300, Alvaro Herrera wrote:
> We already have src/bin/; the mixture of "src/" and "bin/" predates us.
> Of course, the stuff we keep in there is not binaries but source code
> that produces binaries.
>
> As for src/sbin/, we wouldn't install anything to the system's
> /usr/sbin/ of course, only /usr/bin/, just like the stuff in src/bin/.
> But it would be slightly more clear what we keep in each src/ subdir.
I think sbin is a spectactularly bad name, let's not go there. If
anything, make it srvbin or something like that.
> I think our current src/bin/ is a misnomer, but it seems late to fix
> that. In a greenfield I think we could have "src/clients/" and
> "src/srvtools/" or something like that, and everything would install to
> /usr/bin. Then there would be no doubt where to move each program from
> contrib.
Maybe. We could just do that now - git's file change tracking is good
enough for that kind of move.
> Maybe there is no point to all of this and we should just move it all to
> src/bin/ as originally proposed, which is simpler anyway.
+1. Packagers already don't use the current boundaries for packaging...
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
