<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2014-06-12 17:03 GMT+02:00 Rahul Sundaram <span dir="ltr"><<a href="mailto:metherid@gmail.com" target="_blank">metherid@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">On Thu, Jun 12, 2014 at 10:29 AM, Jan Zelený <span dir="ltr"></span> wrote:<br><div><div class="gmail_extra"><div class="gmail_quote"><div class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div><br>
</div></div>We are on the same page, thanks for your input.<br>
<span></span></blockquote><div><br></div></div><div>I don't think so. You are clearly arguing for a temporary compatibility wrapper but eventually forcing everyone to use dnf as the command. The other side is wanting yum to continue to remain the name for the command with yum-legacy for temporary transition. In otherwords, dnf is an internal project name and doesn't need to be exposed to the user.</div>
</div></div></div></div></blockquote><div><br></div></div>There are not only two sides :) I don’t insist on dnf being a hidden “internal project name”; introducing new features (only?) under the dnf name is fine with me. I do object to planning to unnecessarily break the yum commands for which we actually have compatibility.<br>
</div><div class="gmail_extra"> Mirek<br></div></div>