F22 System Wide Change: Replace Yum With DNF

Jon Kent jon.kent at gmail.com
Sat Jun 14 11:18:07 UTC 2014


Been monitoring this debate and if nothing else this seems to point out
that the reasoning for dnf, as opposed to fixing/rewriting yum haven't been
laid out very well. I'm on yum side of the fence as I don't see that the
reasoning so far is been put forward very well for moving to dnf, and that
dnf has crept up on people rather than being 'out there'.

Played with dnf, and from as SA point of view (i.e. mine), I don't see the
difference really, does what I need, which is good.  But then so does yum,
and there lies the problem.  Bad/undocumented api's is not a good reason
for starting something from starch, but a good reason to write this.  At
present, this feels like a pet project, rather than a project with good
reasoning for existing.  I'm sure that not the case, but its not good that
I, and others, feel this well and points to really bad communication.

So my message is simple, write up why dnf is better than yum, from both a
users and devs point of view, then maybe this'll win people over.  Till I
see that, I'll back the guys who want to stick with yum.


On Sat, Jun 14, 2014 at 11:55 AM, Reindl Harald <h.reindl at thelounge.net>

> Am 14.06.2014 12:26, schrieb Michael Scherer:
> > Le samedi 14 juin 2014 à 04:00 +0200, Reindl Harald a écrit :
> >> Am 14.06.2014 03:42, schrieb Michael Scherer:
> >>> Le samedi 14 juin 2014 à 03:33 +0200, Reindl Harald a écrit :
> >>>>> So maybe you should propose to have dnf named yum 4.0, and then since
> >>>>> that's a major version, we would be ok to change the behavior,
> command
> >>>>> lines switch, configuration and backend in a backward incompatible
> >>>>> way?
> >>>>
> >>>> yes
> >>>
> >>> so, just to be clear, that's ok to change the behavior, command lines
> >>> switch, configuratio and backend in backward _incompatible_ for yum 4.0
> >>> aka dnf, for you ?
> >>
> >> it is *NEVER* ok to break user interfaces without a damned good reason
> >> there is no single reason to break command line switches at all
> >
> > So why do you say "yes" at the proposal "that should be ok to break
> > command line switch" if you mean "no" ?
> to show you how weird your "come on let us break compatibility" is
> > So you are in favor of keeping the current behavior as is for how long ?
> > (because it sound like "forever" for you)
> yes forever to say it clear
> if it ain't broken don't fix it
> > Well, yes, because that's the developer that has to make the effort. It
> > is easy to say "do that" and going back to your business. In the end,
> > those who work decide. And so far, I do not see patches coming from you
> i am fine with YUM for many years as others are too
> there was and is no valid reason to break CLI interfaces
> > That's why the developers do ask "what is missing". That's also why I
> > ask for you what compatibility you exactly want, and you keep avoiding
> > giving a clear answer
> *full* compatibility - is that so hard to understand and why?
> > Yes. And I would be in favor personally, so that let developers free to
> > change the interface and anything if they see fit without having to keep
> > old code for the old interface.
> why do you need to keep old code for compatible CLI interfaces?
> > People who want the old yum can keep it alive, the others can use the
> > dnf name
> and because of that attitude Linux don't have that big marketshare
> while often on that list is talked about competitors and marketshare
> you will never gain a large userbase if you signal all the time
> that it's worthless for non-tech users to learn how to deal with
> whatever Linux systems because they have to learn again and again
> how to do the same things instead spend the time for learning
> how to do new things with their computers
> --
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140614/2e9c2197/attachment.html>

More information about the devel mailing list