Thread: [BUGS] pgbouncer-1.7.2-7.rhel6.x86_64.rpm fails to install on AMI
FILE:
https://download.postgresql.org/pub/repos/yum/9.5/redhat/rhel-6-x86_64/pgbouncer-1.7.2-7.rhel6.x86_64.rpm
ERROR
error: Failed dependencies:
libevent2 >= 2.0 is needed by pgbouncer-1.7.2-7.rhel6.x86_64
INFO:
$ cat /etc/os-release
NAME="Amazon Linux AMI"
VERSION="2017.03"
ID="amzn"
ID_LIKE="rhel fedora"
VERSION_ID="2017.03"
PRETTY_NAME="Amazon Linux AMI 2017.03"
ANSI_COLOR="0;33"
CPE_NAME="cpe:/o:amazon:linux:2017.03:ga"
HOME_URL=http://aws.amazon.com/amazon-linux-ami/
Thanks
Eric Joniec
Hi, On Tue, 2017-10-17 at 16:51 +0000, Eric Joniec wrote: > FILE: > https://download.postgresql.org/pub/repos/yum/9.5/redhat/rhel-6-x86_64/pgboun > cer-1.7.2-7.rhel6.x86_64.rpm > > ERROR > error: Failed dependencies: > libevent2 >= 2.0 is needed by pgbouncer-1.7.2-7.rhel6.x86_64 We (community repo) don't support Amazon Linux anymore, because they stopped being compatible with Red Hat. You can play with the SRPM and make changes, for sure. Regards -- Devrim Gündüz EnterpriseDB: https://www.enterprisedb.com PostgreSQL Consultant, Red Hat Certified Engineer Twitter: @DevrimGunduz , @DevrimGunduzTR
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. Greetings, Andres Freund -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
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...
On October 17, 2017 11:49:13 AM PDT, Magnus Hagander > In fact, I seldom come across Amazon's own linux distro there anymore, most people >seem to be using either Ubuntu or CentOS... Not my experience at all. Andres -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
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.
So, in this case, you can fix the build by dropping the "2" in the package name. They seem to have relegated libevent 1.4 to "compat-libevent"
On Tue, Oct 17, 2017 at 9:11 PM, Daniel Farina <daniel@fdr.io> wrote:
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.
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.
(And of course, a good way to get around the ancientness of centos 6 is to use centos 7)
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.
On Thu, Oct 19, 2017 at 7:47 AM, Daniel Farina <daniel@fdr.io> wrote:
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.
That's just my general view of AWS :P
(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.
Certainly, but if you need newer you can go with Fedora. That said -- we're drifting rapidly off-topic.
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.
Presumably we'd have to do something similar to what's done with Fedora, which is rapidly drop support for the old versions. Which would of course decrease the value if people are actually using the old versions of Amazon linux, but presumably they are not doing that if they are on a fast-moving distro.
Devrim can hopefully help out with indications of what would actually be needed for somebody to work on that.