Cannot think much about it right now, no clear answer but will try to comment on it…
First and foremost, updates breaking things can affect every OS and software application.
Locked updates shall prevent things like getting caught by surprise by changes breaking backward compatibility between RHEL 7 versions, or alike, in cases where the sysadmin couldn’t test the updates beforehand.
By locking updates to minor version release:
- no automatic OS “upgrade” is done
- sysadmin has to be notified of availability of new version
- upgrade requires manual intervention
Some user cases:
Apart of missing security updates and patched vulnerabilities, what happens when a server is more than one version behind the current release? Will the notification show the latest available version and will it be able to upgrade to it in an easy way?
@fausp faced the same problem.
From past comments on linked threads, won’t work/sustain unless the process is fully automated.
If EPEL isn’t enabled, we might get failed (dependencies) updates. If enabled, some functionality might be broken by an update. On missing dependencies, an option could be a separate update process with EPEL enabled only for the affected package(s), but if feasible it introduces unwanted complexity (check-update; if failed find cause; if missing dependencies, get affected package and check-update with EPEL enabled).
Would it help to collect pros and cons or a list of issues updates can bring?