On Wed, Jan 08, 2014 at 01:43:01PM -0500, Przemek Klosowski wrote:
>hence that is why whatever calls itself a replacement for yum
should *not*
>support destroy the running system without whatever *force switch*
I don't like the weird partial functionality of this feature. It is
apparently undocumented---actually, it'd be tricky to document it
because it seems to protect some nebulous set of system facilities
(running kernel, current yum, presumably RPM and runtime libraries;
probably also grub; what else?).
I'm a little lost in the thread, but do you mean that yum's protected
packages functionality is undocumented? If that is what you mean, check the
man page. It says:
protected_packages This is a list of packages that yum should
never completely remove. They are protected via Obsoletes as
well as user/plugin removals.
The default is: yum glob:/etc/yum/protected.d/*.conf So any
packages which should be protected can do so by including a file
in /etc/yum/protected.d with their package name in it.
Also if this configuration is set to anything, then yum will
protect the package corresponding to the running version of the
kernel.
And on _my_ system, there's a /etc/yum/protected.d/systemd.conf containing
owned by "systemd" and a gnome.conf containing gnome-shell which I think I
put there myself. (Nothing owns it and I don't remember.)
This goes an amazingly long way toward protecting the system from accidental
autophagy without really being all that complex.
Another point: it shouldn't be hardwired into the package
manager
but rather result from package properties. I can see several ways to
do it:
- an 'essentiality' property in the RPM file
- a yum/dnf configuration file specifying a set of protected packages
- a special, unremovable 'system' package that depends on kernel and dnf
Option #2 it is.
Last two would be preferable, because they allow tailoring the set
of protected packages differently for a datacenter server vs. a
network appliance, desktop, etc.
Exactly. And configuration is better than a magic package.
--
Matthew Miller -- Fedora Project -- <mattdm(a)fedoraproject.org>