<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2014-06-11 17:20 GMT+02:00 Jan Zelený <span dir="ltr"><<a href="mailto:jzeleny@redhat.com" target="_blank">jzeleny@redhat.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class=""><div class="h5">Also, dnf<br>
> needs to drop all the legacy options before the transition (ie) pick erase<br>
> or remove (preferably the latter) etc rather than retain all the<br>
> compatibility options.<br>
<br>
</div></div>The transition period is one reason why we want to keep the name dnf.</blockquote><div><br></div><div>The compatibility options can be kept in /usr/bin/yum without cluttering up /usr/bin/dnf.<br></div><div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Also presenting dnf as a separate project forked from yum gives us better<br>
flexibility - for instance it's easier to drop obsoleted stuff because users<br>
don't have that high compatibility expectations.<br></blockquote><br></div>That’s a pure illusion. The users have a compatibility expectation that <i>their software will continue working</i>. Compared to asking the users to notice and work around removal of “obsoleted stuff” in /usr/bin/yum, asking the users to notice and work around removal of “obsoleted stuff” in /usr/bin/yum <i>and in addition to change the command name in their scripts</i> is, AFAICT, just making things worse.<br>
</div><div class="gmail_extra"> Mirek<br></div></div>