<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Jun 14, 2014 at 3:56 PM, Björn Persson <span dir="ltr">&lt;<a href="mailto:bjorn@xn--rombobjrn-67a.se" target="_blank">bjorn@xn--rombobjrn-67a.se</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Please keep the command name &quot;yum&quot;, and keep the command line syntax<br>
and the configuration language as compatible as is feasible. Make a<br>
wrapper or a symlink if you need to, but plan to keep it forever, not<br>
just for a year or two.<br>
<br>
So Yum has been made faster? That&#39;s wonderful news, it was certainly<br>
needed. It&#39;s been redesigned and largely rewritten? OK, great, I<br>
understand that the new design is better. If there was some feature that<br>
turned out to be a misfeature and had to be removed, well that&#39;s<br>
unfortunate but it happens. Remove the misfeature, document that it&#39;s<br>
gone and that it was a bad idea from the beginning, and print an<br>
informative error message when someone tries to use it. If a feature<br>
that was optional before is now always enabled, then keep the option as<br>
a no-op and document that it has no effect anymore. As a user of Yum I<br>
don&#39;t see any of that as a reason to change the command name.<br>
<br>
As a system administrator I expect &quot;yum install&quot;, &quot;yum remove&quot; and<br>
&quot;yum update&quot; to continue to work, and I expect to not have to rename or<br>
edit /etc/yum.conf after an upgrade. I&#39;m sure I&#39;m far from alone.<br>
<br>
As a fellow programmer I can understand that you want to use a new name<br>
for this new and improved program that you have invested a lot of work<br>
in, but I also know how annoyed I would be if I had scripts calling Yum,<br>
and had to modify them to keep them working. A command line interface<br>
is also an API, and I want APIs to be as stable as possible so I can<br>
spend my time writing new programs instead of rewriting old programs<br>
just to keep existing functionality. It&#39;s particularly painful when a<br>
program must be ported or branched to work on different systems, for<br>
example Fedora and RHEL, because one has only the old API and the other<br>
has only the new API.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Björn Persson<br>
</font></span><br>--<br>
devel mailing list<br>
<a href="mailto:devel@lists.fedoraproject.org">devel@lists.fedoraproject.org</a><br>
<a href="https://admin.fedoraproject.org/mailman/listinfo/devel" target="_blank">https://admin.fedoraproject.org/mailman/listinfo/devel</a><br>
Fedora Code of Conduct: <a href="http://fedoraproject.org/code-of-conduct" target="_blank">http://fedoraproject.org/code-of-conduct</a><br></blockquote></div><br></div><div class="gmail_extra">Amen. I&#39;ve been wanting to chime in here, but this is exactly how I feel on the issue and you&#39;ve said it better than I could have.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Ben Rosser</div></div>