On Sat, Jun 14, 2014 at 3:56 PM, Björn Persson <bjorn@xxxxxxxxxxxxxxxxxxxx> 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. The name change is gong to break every 'chef' cookbook that uses the 'yum_package' utility, until chef can be profoundly upgraded to support dnf. Similar issues will occur with cfengine and many, many other system management utilities. I think the name change helps make clear that it's an architectural change. > So Yum has been made faster? That's wonderful news, it was certainly > needed. It's been redesigned and largely rewritten? OK, great, I I'm afraid that It's also a fairly irrelevant speed improvement. Many of the underlying delays in yum are due to the excessively bulky repodata, which requires complete binary replacement every time yum metadata expires due to its overburdened and monolithic compressed binary format. Unless 'repodata' is extensively rewritten, with much smaller and easily synchronzed components and not this monolithinc and increasingly encumbered SQLite database of doom, small operations such as "yum check-updates" are likely to continue to suck bandwidth, CPU, and resources excessively every time they get run. If you think I'm kidding, switch to a local yum mirror and check the logs for *just how many times*, the repodata gets downloaded with standard configurations in a busy environment. The bandwidth saved by using delta-rpms is completely irrelevant compared to the expensive repodata refreshes, themselves, in an environment where yum checks, or system tools that verify yum dependencies, run even once a day. Frankly, improving that might be enormously helpful to the Fedora mirrors themselves. The investment in server side operations to check a larger list of smaller and more stable metadata components would, I think, be well justified by replacing the quite builky, monolithic, and expiration envorced sqlite database files. I'd love to see dnf speed improvements improve the behavior of tools like 'mock', which rely so heavily on yum updates. But given the bandwidth and resource constraints of repodata churn, I don't think it's gonna happen. > 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. That's why they're changing the name: it's a major architectural shift in a core component, and continuing to call it yum, could be confusing. > 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. And the API changing is pretty profound. It's a different API, thus a different function name. And yeah, I'm not personally looking forward to it. I still loathe the switch to systemd for systems I maintain in multiple environments. > -- > Björn Persson > > -- > devel mailing list > devel@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
