Has anybody enabled this repo?
I understand that it can really mess up updates and upgrades as the dependencies are rather different.
7 thoughts on - CentOSPlus
I’ve had the CentOSPlus repository enabled for CentOS6 for more than a year with no problems. I don’t recall reading anything on this mailing list or IRC suggesting that enabling plus caused issues with updates.
The CentOS wiki warns “Enabling this repository makes CentOS
different from upstream. You should understand the implications of this prior to enabling CentOSPlus”. Essentially this is a reminder that the CentOS community has no appetite for supporting slightly non-standard configurations (a very reasonable stance).
If you need the extra hardware driver modules available with Plus this shouldn’t stop you from running a Plus kernel. Just be prepared to reproduce any problems using a stock kernel (which you can still select at boot) if you need to resolve an OS issue with help from others.
The only vhanged packages in the CentOS Plus 6 repo are the kernel (kernel, kernel-abi-whitelist, kernel-doc, kernel-firmware, kernel-headers, kernel-devel), the kernel performance utilities (perf, python-perf), and postfix.
sed -i -e ‘s/^enabled=1/enabled=0/’ /etc/yum.repos.d/epel.repo
and manually enable it when you need to get a package from said repo:
yum install -y libmcrypt –enablerepo=epel
Hello Mauricio,
I understand. For systems with a few packages from Epel this is my favored technique. Epel has a lot more packages that overlap or interact with base repo packages, if I’m not mistaken. But for my CentOSPlus repository use case, I leave the repo enabled in the config file; forgetting to re-enable it could leave these systems without neccessary drivers. As the repository contents is desired _in total_ over the base packages, there’s no down side for this use.
Doing this means you won’t get notified of updates in that repo. This is not a good idea.
I see your point since you can setup repo priorities
. . .
Having been bitten by this on several occasions I finally adopted the policy of using the — includepkgs= — option and specifically naming the packages that I want from a non-standard repo; and also using
James B. Byrne wrote:
Agreed. This is what I do on the systems with NVidia cards, and I want kmod-nvidia – I have include= in the /etc/yum.repos.d/elrepo.repo.
Then, to protect production systems from “update everywhere!!!”, in
/etc/yum.conf, *just* on those systems, I’ll have thinks like exclude=httpd,kernel. When I have my maintenance window to really update, I do a yum update –disableexcludes=all. Gives me a fine-grained control.
7 thoughts on - CentOSPlus
I’ve had the CentOSPlus repository enabled for CentOS6 for more than a year with no problems. I don’t recall reading anything on this mailing list or IRC suggesting that enabling plus caused issues with updates.
The CentOS wiki warns “Enabling this repository makes CentOS
different from upstream. You should understand the implications of this prior to enabling CentOSPlus”. Essentially this is a reminder that the CentOS community has no appetite for supporting slightly non-standard configurations (a very reasonable stance).
If you need the extra hardware driver modules available with Plus this shouldn’t stop you from running a Plus kernel. Just be prepared to reproduce any problems using a stock kernel (which you can still select at boot) if you need to resolve an OS issue with help from others.
The only vhanged packages in the CentOS Plus 6 repo are the kernel (kernel, kernel-abi-whitelist, kernel-doc, kernel-firmware, kernel-headers, kernel-devel), the kernel performance utilities (perf, python-perf), and postfix.
For detailed differences of the “Plus” kernel see:
https://wiki.CentOS.org/AdditionalResources/Repositories/CentOSPlus?action=show&redirect=Repositories%2FCentOSPlus#head-a94637ae716c01023f633e8b5fb840f555f6d378
HTH, HAND,
Why not leave all the extra repos disabled, say
sed -i -e ‘s/^enabled=1/enabled=0/’ /etc/yum.repos.d/epel.repo
and manually enable it when you need to get a package from said repo:
yum install -y libmcrypt –enablerepo=epel
Hello Mauricio,
I understand. For systems with a few packages from Epel this is my favored technique. Epel has a lot more packages that overlap or interact with base repo packages, if I’m not mistaken. But for my CentOSPlus repository use case, I leave the repo enabled in the config file; forgetting to re-enable it could leave these systems without neccessary drivers. As the repository contents is desired _in total_ over the base packages, there’s no down side for this use.
https://wiki.CentOS.org/AdditionalResources/Repositories/CentOSPlus?action=show&redirect=Repositories%2FCentOSPlus#head-a94637ae716c01023f633e8b5fb840f555f6d378
Doing this means you won’t get notified of updates in that repo. This is not a good idea.
I see your point since you can setup repo priorities
. . .
Having been bitten by this on several occasions I finally adopted the policy of using the — includepkgs= — option and specifically naming the packages that I want from a non-standard repo; and also using
James B. Byrne wrote:
Agreed. This is what I do on the systems with NVidia cards, and I want kmod-nvidia – I have include= in the /etc/yum.repos.d/elrepo.repo.
Then, to protect production systems from “update everywhere!!!”, in
/etc/yum.conf, *just* on those systems, I’ll have thinks like exclude=httpd,kernel. When I have my maintenance window to really update, I do a yum update –disableexcludes=all. Gives me a fine-grained control.
mark