Does this issue only occur when both repos are installed on a system? Otherwise I expect we'd have learned about this long ago. How can this be reproduced?

I can't duplicate the problem as described. Steps I took in my attempt:

1. Update my CentOS 7 machine to latest with:
   yum update
2. Confirm the Jenkins repo is not in the repolist with:
   sudo yum repolist | grep jenkins
3. Install jenkins.repo into /etc/yum.repos.d/ with:
   sudo wget -O /etc/yum.repos.d/jenkins.repo https://pkg.jenkins.io/redhat-stable/jenkins.repo
4. Install the Jenkins repository signature with:
   sudo rpm --import https://pkg.jenkins.io/redhat-stable/jenkins.io.key
5. Confirm the Jenkins repo is in the repolist with:
   sudo yum repolist | grep jenkins
6. Install Jenkins and confirm it is latest LTS (2.73.3) with:
   sudo yum install jenkins

The message reported by the glajchs looks similar to messages I've seen when a mirror was temporarily unavailable. Does the reported problem still appear? Does it continue if you use a different mirror?

markewaite Note the version it tries to download, 2.89 isn't stable.

Perhaps installing both repos as my comment suggests works?

danielbeck I agree that the description from glajchs says that his download was attempting 2.89, and if that is the version being attempted from "stable", then that is a bug.

My results were that it downloaded 2.73.3 as I expected. I am unable to duplicate the bug as reported. Have you been able to duplicate the bug as reported?

danielbeck I don't know how Red Hat thinks about packages, but I believe the Debian and Ubuntu packages don't use a separate name for the long term support release of something as compared to weekly releases.  I assumed the same for Red Hat, since the package name is "jenkins" in both cases. 

I assume that it is expected the user will choose one package source or the other.  Choosing both package sources seems like a "recipe for chaos", since then the same package name can be delivered from multiple repositories.

Am I understanding your line of thinking, that possibly glajchs had configured both the stable and the weekly repositories of Jenkins on a single machine, then requested a jenkins installation without specifying a package version to install?

Hi, sorry for the delay in response. I was fairly sure that I had only configured the stable repo entry for jenkins on the machine in question, however my "yum-fu" is not super great. I'm used to the debian package managers. I ran "sudo yum repolist enabled" and I only found the one entry for "jenkins-stable". Listing the disabled repos didn't list any other jenkins repos.

That being said, this machine is really old, and did have a very old verison of jenkins installed on it. I can't find the actual version now but it's 1.5x. This was done a few years ago, and I'm pretty sure at the time I had used the RPM file directly to install, and not a yum repo.

Again this an amazon-linux machine, which is RHEL based, but they do a bunch of custom stuff to those images so I'm not sure how much that plays into this. I'm not sure I can instantiate a new machine and dig into this too much more, but at the very least since this issue is limited to some set of machines or configurations, you might want to bump it down from major to normal priority.

Here is a gist of the output of the yum repolist command, and the machine/release info: https://gist.github.com/glajchs/1da67cb5b16577558b64c36f7d957c7b

Not sure there's something to gain from a continued investigation when the system config could just be messed up somehow, and we cannot reproduce it.