Bug 955673

Summary:	[rfe] protected_packages feature in dnf
Product:	[Fedora] Fedora	Reporter:	Rahul Sundaram <metherid>
Component:	dnf	Assignee:	Ales Kozumplik <akozumpl>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	ahmadsamir3891, akozumpl, jzeleny, pmatilai, robatino
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-04-24 08:19:34 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Rahul Sundaram 2013-04-23 13:58:29 UTC

Description of problem:

yum has a protected_packages feature that disables the ability to remove yum with yum itself by default but dnf seems to lack it.  dnf remove dnf works fine and i haven't tried dnf remove yum but suspect it might work as well.

Comment 1 Ales Kozumplik 2013-04-24 06:24:49 UTC

I don't consider this a systematic Yum feature and so don't plan to support this in DNF. If you want to do 'dnf remove dnf' then by all means do it.

Thanks for the report anyway, this yum/dnf incompatibility should be documented.

Comment 2 Ales Kozumplik 2013-04-24 08:19:34 UTC

Documentation added in d0224a5:

http://akozumpl.github.io/dnf/cli_vs_yum.html#protected-packages-is-ignored

closing as NOTABUG.

Comment 3 Panu Matilainen 2014-01-03 07:29:52 UTC

I think the protected packages as a *mechanism* is a highly useful one and should be kept around, one way or the other (see below). However *populating* the data is an entirely different matter - for example figuring the mapping between currently running kernel and some installed package is a very distro-specific thing and is best left to a distro-specific plugin.

It'd be possible to implement rpm-level enforcement for install/erase/upgrade/obsolete prevention mechanism, settable on per-package basis (inherited across upgrades I suppose, maybe even obsoletes). James wasn't thrilled wrt such a thing for yum as it already had its own mechanism at the time this option came up, but perhaps here would be a chance to rethink the situation. Note that rpm would also only provide a mechanism, not policy.