<div dir="ltr">Hi<br><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jan 3, 2014 at 7:01 AM, Michael Scherer <span dir="ltr"></span>wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I could see a few. having a plugin permit to have it more extensible.<br>
For example, let's say I want to have a system that act a bit smarter,<br>
and prevent removing kernel, and several others stuff depending on the<br>
hostname ( ie, in a classroom where people are using VM to test ). Or<br>
imagine I want to let kernel be removed because the system is in a<br>
container, so I can detect the container type and decide to let people<br>
remove or not.<br>
<br>
If all is set in stone in the main software, then we can hardly permit<br>
theses use cases.<br></blockquote><div><br></div><div>It is not quite either/or though. I would say, providing some safety as part of the core and have plugins extend the base model with extra features is the right approach here as opposed to delegating it entirely to a plugin and have that plugin installed by default. In any case, if dnf developers were not opposed to having this level of safety from being there by default, it wouldn't be really an issue regardless of whether the feature is implementing via a plugin or not which is an implementation detail most users wouldn't be concerned about.<br>
<br></div><div>Rahul <br></div></div></div></div></div>