F22 System Wide Change: Replace Yum With DNF

Ben Rosser rosser.bjr at gmail.com
Sat Jun 14 21:05:12 UTC 2014


On Sat, Jun 14, 2014 at 3:56 PM, Björn Persson <bjorn at xn--rombobjrn-67a.se>
wrote:

> Please keep the command name "yum", and keep the command line syntax
> and the configuration language as compatible as is feasible. Make a
> wrapper or a symlink if you need to, but plan to keep it forever, not
> just for a year or two.
>
> So Yum has been made faster? That's wonderful news, it was certainly
> needed. It's been redesigned and largely rewritten? OK, great, I
> understand that the new design is better. If there was some feature that
> turned out to be a misfeature and had to be removed, well that's
> unfortunate but it happens. Remove the misfeature, document that it's
> gone and that it was a bad idea from the beginning, and print an
> informative error message when someone tries to use it. If a feature
> that was optional before is now always enabled, then keep the option as
> a no-op and document that it has no effect anymore. As a user of Yum I
> don't see any of that as a reason to change the command name.
>
> As a system administrator I expect "yum install", "yum remove" and
> "yum update" to continue to work, and I expect to not have to rename or
> edit /etc/yum.conf after an upgrade. I'm sure I'm far from alone.
>
> As a fellow programmer I can understand that you want to use a new name
> for this new and improved program that you have invested a lot of work
> in, but I also know how annoyed I would be if I had scripts calling Yum,
> and had to modify them to keep them working. A command line interface
> is also an API, and I want APIs to be as stable as possible so I can
> spend my time writing new programs instead of rewriting old programs
> just to keep existing functionality. It's particularly painful when a
> program must be ported or branched to work on different systems, for
> example Fedora and RHEL, because one has only the old API and the other
> has only the new API.
>
> --
> Björn Persson
>
> --
> devel mailing list
> devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>

Amen. I've been wanting to chime in here, but this is exactly how I feel on
the issue and you've said it better than I could have.

Ben Rosser
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140614/370f53a9/attachment-0001.html>


More information about the devel mailing list