Status: Resolved (View Workflow)
The file /etc/yum.repos.d/jenkins.repo belongs to the jenkins package.
This is IMHO a non-sense. Please think about people that integrate jenkins with other repository system (e.g. pulp).
It is not bad to have a repo in a RPM, but other tools/repos like EPEL have a dedicated RPM besides other rpms.
So I propose to split the jenkins-repo rpm from the jenkins rpm.
JENKINS-22690 RPM install jenkins.repo file
- is related to
JENKINS-12757 It is not possible to use the RedHat/Fedora/Centos RPM:s on a private network.
i also agree, we have an pulp server for rpm, and all internal servers connect to this server instead of an external url, with this repo file included, yum breaks with error, can not connect, so we always need to ensure that the repo file is removed.
please fix this!
FWIW, I agree too. I'm install Jenkins on a closed network, so the repo file is entirely useless, and actually breaks 'yum' because it's unable to connect to the Jenkins repo server. I've solved the problem by installing Jenkins with Puppet and having it alter the repo file to put 'enabled=0' into it. For cases where Jenkins isn't installed with Puppet, I've put some post-install into a few other commonly used packages to do the same thing. All should be unneccessary - splitting the RPM would be a great help.
Update: Looks like this is fixed: https://issues.jenkins-ci.org/browse/JENKINS-22690
The fix has been submitted (see
I fully agree.
Yum repository information should not be stored in the main jenkins RPM.
A unwelcome side-effect of this is that the file /etc/yum.repos.d/jenkins.repo is removed when the Jenkins RPM is removed from the system.
This forces a server-administrator to (manually) place the jenkins.repo file on the server again.
Most of the time this kind yum repository information is stored in a separate *-release.rpm
For jenkins this RPM would be named as: jenkins-release.rpm
A nice example for this can be fedora-release-18-1.noarch.rpm or rpmfusion-free-release-18-3.noarch