On Tue, Dec 8, 2015 at 1:35 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> I don't really want to get into an argument about this, but is the >> reason we haven't updated config.guess and config.sub in the past that >> it presents an actual stability risk, or just that nobody's asked >> before? Because the first one is a good reason not to do it now, but >> the second one isn't. > > Well, I see at least one case in the git history where we explicitly > declined to update config.guess/config.sub: > > Author: Tom Lane <t...@sss.pgh.pa.us> > Branch: master Release: REL9_3_BR [5c7603c31] 2013-06-04 15:42:02 -0400 > Branch: REL9_2_STABLE Release: REL9_2_5 [612ecf311] 2013-06-04 15:42:21 -0400 > > Add ARM64 (aarch64) support to s_lock.h. > > Use the same gcc atomic functions as we do on newer ARM chips. > (Basically this is a copy and paste of the __arm__ code block, > but omitting the SWPB option since that definitely won't work.) > > Back-patch to 9.2. The patch would work further back, but we'd also > need to update config.guess/config.sub in older branches to make them > build out-of-the-box, and there hasn't been demand for it. > > Mark Salter
Right, but that commit cites lack of demand, rather than anything else. > More generally, I think "does updating config.guess, in itself, pose > a stability risk" is a false statement of the issue. The real issue is > do we want to start supporting a new platform in 9.1-9.3; that is, IMO > if we accept this request then we are buying into doing *whatever is > needed* to support ppc64le on those branches. Maybe that will stop with > config.guess/config.sub, or maybe it won't. I'm sympathetic to that concern. On the other hand, if somebody were to discover, say, a bug in s_lock.h that causes a compile failure on ppcle, I think we'd treat that as a back-patchable fix and whack it into all supported branches. If somebody were to come along and say, you can't use GetWeirdWindowsCrap() on the latest verison of Windows, you have to instead use GetDumbWindowsCrap(), we would presumably back-patch that as far as convenient also. Are those kind of changes adding support for a new platform, or just fixing bugs? Now, on the flip side, the original port to Windows was not back-patched, nor should it have been: that was clearly major new development, not just tweaking. With respect to this particular thing, it's hard for me to imagine that anything will go wrong on ppcle that we wouldn't consider a back-patchable fix, so there might be no harm in adjusting config.guess and config.sub. On the other hand, maybe it'd be better to get the buildfarm critter set up first (using the workaround Andrew suggested) and then reevaluate. If it seems to work, I see little harm in saying, oh yeah sure it's supported, but we don't actually know that yet. > Setting this precedent will also make it quite hard to reject future > requests to back-patch support for other new platforms. > > I'm not planning to go to war about this issue either. But I do think > there's a slippery-slope hazard here, and we should be prepared for > the logical consequences of accepting such a request. Or if we're > going to have a policy allowing this request but not every such request, > somebody had better enunciate what that policy is. I don't have a real clear opinion about this just at the moment, but I think "those changes look scary to back-patch" is a pretty decent heuristic. "That looks like new development" is another one I'd feel confident to deploy. > (BTW, so far as direct stability hazards go, I would guess that the > key question is how much version skew can be tolerated between autoconf > and config.guess/config.sub. I have no idea about that; Peter E. might. > But I do note that pre-9.4 branches use an older autoconf version.) That's a good question, and I wonder if this is why it works from 9.4. I don't remember an explicit decision to begin supporting ppcle, and I'm not sure in any case that I'd endorse the view that whatever config.guess has heard of, we support. I thought the policy was more like "whatever we have a working BF member for, we support". -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
