F22 System Wide Change: Replace Yum With DNF

[Michael Scherer]

Le samedi 14 juin 2014 à 15:15 +0200, Reindl Harald a écrit :
> 
> Am 14.06.2014 15:04, schrieb Michael Scherer:
> > Le samedi 14 juin 2014 à 12:55 +0200, Reindl Harald a écrit :
> >>> 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?
> > 
> > So basically, you want "full compatibility forever". Then I guess you
> > cannot say that nobody ask for that, since you just did.
> > 
> > https://lists.fedoraproject.org/pipermail/devel/2014-June/199991.html
> 
> stop that trolling
>
> "to maintain yum in the long term" is a completly different thing than
> keep *full compatibility* - compatibility is independet from the YUM
> code itself

Given there is no specification of what you mean by "full
compatibility", the compatibility is the current behaviour in every
details, and the current behaviour is therefore linked to the current
code. 

Now, if someone do say "here is what we consider to be
compatible" ( something that you have been asked 3 times and yet didn't
provide, not even tried to provides ), then the compatibility would be
separate from the code. But as long as "full compatibility" is "what yum
does now", the 2 are linked by definition.

But again, can you give a more precise definition of the behaviour that
should be kept without having to refer to yum code ?
You do not even say what version of the yum code should be used as
reference.

> > Yet, I still do not see you offering any help to achieve that, only you
> > requiring it.
> 
> as you do not offering to do the work of re-view and adopt
> any existing script and howto out there

I did intend to work on ansible to have it using dnf API, as that's a
codebase I know quite well. 


> >>> 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?
> > 
> > Because that's the easiest way, especially for plugins. 
> 
> interesting - guess what: the *easiest way* would have been
> not rewrite YUM at all - do it anyways but than say "but
> for all other things which don't match the cherry picking
> it's easier not do to so" is hypocrisy

So basically, that exactly what I said. It is is easier to keep the old
code than to ask to keep compatibility in the new one, especially since
compatibility is not specified at all. 

So if your goal is 100% compatibility over all, then indeed, not
changing anything is the simplest way. Now, if you want to see some
changes, then you are ok to have something change, so the goal is no
longer 100%. So you have to explain what are the 90% that shouldn't
changes at all, and what are the 10% that you are ok to see changes.


> > Otherwise, any changes could result in unrelated side effects and
> > regressions, and the more options you provides, the more stuff there is
> > to break. And the QA cost of full compatibility is rather high,
> > especially for python where there isn't much isolation or interface for
> > the code ( ie, you can directly go to the internal structures, kinda
> > like DOS years ago )
> 
> you understand that any compatibility break is a side effect for the user?

Yes, I do. That doesn't mean that I care however. 

I am personally ok with having some breakages if the developers think
this is the better choice given time, contraints and all real life
issues, as I trust them to have thought about it. And I do not care also
because I am fully able to adapt, that's part of my job as sysadmin.

-- 
Michael Scherer