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@xxxxxxxxxxxxxxxxx> -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
