Обсуждение: [BUGS] pgbouncer-1.7.2-7.rhel6.x86_64.rpm fails to install on AMI

Hi,

On 2017-10-17 19:39:00 +0100, Devrim Gündüz wrote:
> We (community repo) don't support Amazon Linux anymore, because they stopped
> being compatible with Red Hat.

Given the amount of installations that seems like a fairly radical
thing.

On Tue, Oct 17, 2017 at 11:49 AM Magnus Hagander <magnus@hagander.net> wrote:

On Tue, Oct 17, 2017 at 8:44 PM, Andres Freund <andres@anarazel.de> wrote:

Hi,

On 2017-10-17 19:39:00 +0100, Devrim Gündüz wrote:
> We (community repo) don't support Amazon Linux anymore, because they stopped
> being compatible with Red Hat.

Given the amount of installations that seems like a fairly radical
thing.

Given that most of the other distros supported on Amazon are supported by the repo, I don't see it as a big problem in general, TBH. In fact, I seldom come across Amazon's own linux distro there anymore, most people seem to be using either Ubuntu or CentOS...

I use it. It's the only way (I know of) to get Amazon to do support for kernel issues. Even as compared to Redhat, they will take a look at live crashed instances having problems...nobody else has that access. And as far as I know, they use it too, and perform quality assurance on it on their platform. Solution or workaround for that class of bugs is not particularly portable to other Linux distributions. 

In general, I have found Amazon Linux an easier target in most respects: one can drop workarounds to cope with the ancientness of CentOS6. Notably, access to new libraries (e.g. libcurl) allow easier updates to libraries like gdal or geos with fewer patches to cope with old compilers (by installing gcc64-c++). It also tends to have new kernels that are lightly modified to deal with specific issues (per changelog).

Amazon Linux however, different, and makes releases that move rather quickly. It's rather closer to Fedora in a way.

Sometimes, as with programming languages, they are fairly fastidious at separating out old versions of packages (e.g. pip-3.4, pip-3.5, pip-3.6 for Python), and for better or worse, sometimes, in cases like gcc, libevent, libcurl, or boost, they'll Just Upgrade.

On Wed, Oct 18, 2017 at 1:17 AM Magnus Hagander <magnus@hagander.net> wrote:

I guess our experiences are different. I've never had the need for kernel level bugs on such instances. I have had countless of customers had their stuff broken by random incompatible upgrades pushed out in a way that even Fedora wouldn't do. Those problems all went away when people stopped using Amazon Linux.

Yeeeah. I've hit a couple, and when they bite, it's kind of catastrophically difficult to do anything about it. They're the only ones in the position to do efficient debugging.

(And of course, a good way to get around the ancientness of centos 6 is to use centos 7) 

7 is often not as new as Amazon Linux (modulo systemd?), for better and for worse.

Anyway. A fast moving distro with large number of backwards incompatible changes is obviously a huge hassle for the people maintaining the RPMs. I can't really fault them for not dealing with that, since it's on volunteer basis. Might be selection bias that makes them not exposed to the userbase.

It's a fast moving target for sure. And who will appreciate it? And how long should one support old versions of Amazon Linux given their frequency (it probably ca't be long?) Hard to say. It doesn't make much sense to support it akin to CentOS 6, that's for sure.

I think the first step is to survey the wreckage of trying to build the entire suite of packages. I have no idea how to do that, though.