F22 System Wide Change: Replace Yum With DNF

Michael Scherer misc at zarb.org
Sat Jun 14 10:26:10 UTC 2014

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" ?

So you are in favor of keeping the current behavior as is for how long ?
( because it sound like "forever" for you )

> >>> Or even with the name yum and a clear indication, that's something that
> >>> shouldn't be changed, in which case, yum 3 behavior should be kept,
> >>> which mean "keeping all the code and behavior until later" ?
> >>
> >> jesus christ the code behind has *nothing* to do with the userinterface
> >> and options - i have rewritten code of software i maintain for a decade
> >> now multiple times and in the meantime there is for sure not a single
> >> line the same as started 2003 without break user expectations
> > 
> > In the case of dnf, the plugin api did changed. And I doubt people want
> > to bring back the old one. So the user expectation around specific
> > plugin is already broken. 
> no - only if you want it that way as developer

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.

Michael Scherer

More information about the devel mailing list