pgbouncer-1.7.2-7.rhel6.x86_64.rpm fails to install on AMI
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.rpmERROR
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...
--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/>
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
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)
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.
--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/>
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
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.
--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/>
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>