<div dir="ltr"> Hi<br><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jan 2, 2014 at 3:52 PM, Matthew Miller <span dir="ltr"></span>wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">This one is clearly one of those "doomed to repeat history" things in<br>
motion.<br>
<br>
Protected packages was first implemented * as a yum plugin because Seth<br>
thought it was kind of crazy and shouldn't be core functionality, but then<br>
it proved itself in real use and became built-in. Now, the DNF pages says<br>
"Similar functionality can be implemented by a plugin", putting us right<br>
back where we were. **<br></blockquote><div><br></div><div>Pretty much, yeah. I remember trying to convince Seth to merge the functionality and got pretty similar replies to what I hear from Ales now. Similar issues at <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1044984">https://bugzilla.redhat.com/show_bug.cgi?id=1044984</a> and <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1044984">https://bugzilla.redhat.com/show_bug.cgi?id=1044984</a>. I really dislike going through the same process twice. Pushing such functionality out into plugins won't work well either because by the time users realize that such a plugin exists and they might need them, it is likely to be too late and if you discard existing features without understanding the use cases fully, you will end up creating a rough transition for users. If someone is going to replace A with B, it would be nice for the developers involved to go through the release history and bugs and find out why the current functionality was done the way it was before deciding to change it. <br>
<br></div><div>Rahul<br></div><div> <br></div></div></div></div></div>