On Sat, Jun 6, 2015 at 7:35 AM, Geoff Winkless <pgsqlad...@geoff.dj> wrote:
> On 6 June 2015 at 13:41, Sehrope Sarkuni <sehr...@jackdb.com> wrote: > >> >> > It's much easier to work into dev/test setups if there are system >> packages as it's just a config change to an existing script. Building >> from source would require a whole new workflow that I don't have time >> to incorporate. >> > > Really? You genuinely don't have time to paste, say: > > mkdir -p ~/src/pgdevel > cd ~/src/pgdevel > wget > https://ftp.postgresql.org/pub/snapshot/dev/postgresql-snapshot.tar.bz2 > tar xjf postgresql-snapshot.tar.bz2 > mkdir bld > > cd bld > ../postgresql-9.5devel/configure $(pg_config --configure | sed -e > 's/\(pg\|postgresql[-\/]\)\(doc-\)\?9\.[0-9]*\(dev\)\?/\1\29.5dev/g') > make wor > ld > make check > make world-install > I think this is rather uncharitable. You don't include yum, zypper, or apt-get anywhere in there, and I vaguely recall it took me quite a bit of time to install all the prereqs in order to get it to compile several years ago when I first started trying to compile it. And then even more time get it to compile with several of the config flags I wanted. And then even more time to get the docs to compile. And now after I got all of that, when I try your code, it still doesn't work. $(pg_config ....) seems to not quote things the way that configure wants them quoted, or something. And the package from which I was using pg_config uses more config options than I was set up for when compiling myself, so I either have to manually remove the flags, or find more dependencies (pam, xslt, ossp-uuid, tcl, tcl-dev, and counting). This is not very fun, and I didn't even need to get bureaucratic approval to do any of this stuff, like a lot of people do. And then when I try to install it, it tries to overwrite some of the files which were initially installed by the package manager in /usr/lib. That doesn't seem good. And how do I, as a hypothetical package manager user, start this puppy up? Where is pg_ctlcluster? How does one do pg_upgrade between a package-controlled data directory and this new binary? And then when I find a bug, how do I know it is a bug and not me doing something wrong in the build process, and getting the wrong .so to load with the wrong binary or something like that? > and yet you think you have enough time to provide more than a "looks like > it's working" report to the developers? > If it isn't working, reports of it isn't working with error messages are pretty helpful and don't take a whole lot of time. If it is working, reports of that probably aren't terribly helpful without putting a lot more work into it. But people might be willing to put a lot of work into, say, performance regression testing it that is their area of expertise, if they don' t also have to put a lot of work into getting the software to compile in the first place, which is not their area. Now I don't see a lot of evidence of beta testing from the public (i.e. unfamiliar names) on -hackers and -bugs lists. But a lot of hackers report things that "a client" or "someone on IRC" reported to them, so I'm willing to believe that a lot of useful beta testing does go on, even though I don't directly see it, and if there were alpha releases, why wouldn't it extend to that? > > (NB the sed for the pg_config line will probably need work, it looks like > it should work on the two types of system I have here but I have to admit I > changed the config line manually when I built it) > Right, and are the people who use apt-get to install everything likely to know how to do that work? Cheers, Jeff