F22 System Wide Change: Replace Yum With DNF
misc at zarb.org
Sat Jun 14 10:39:29 UTC 2014
Le samedi 14 juin 2014 à 03:55 +0200, Reindl Harald a écrit :
> Am 14.06.2014 03:36, schrieb Michael Scherer:
> > Everybody I know who looked at the yum python api told me it was a bit
> > horrible. So a cleanup was needed for that. There was demand from
> > packagekit developers to have a cleaner API as well, and I would hope
> > that tools like puppet/ansible would benefit as well.
> > And since that's python, you also have the need to be python 3
> > compatible, which is a rather big task, as seen by the slow migration of
> > the rest of the platform.
> > The less code you have to port, the less time it take (same goes for
> > testing, documenting, translating)
> the internal API is between developers
> the options and CLI params are for users
> different worlds
This divide is meaningless, since what affect developers affect non
developers ( as code that is not ported will no longer work, even for
API change ), and as people keep speaking of scripts on yum. The command
line switches are part of the API for software like puppet, ansible.
> >> if someone takes the word "improve" in his mouth i
> >> don't see a place for "remove" in the same context
> >> the "dirty codebase grown" that way because previously unplanned
> >> features where included and it it pretty silly to cleanup things
> >> by step back from where it came which leads a few years later to
> >> the same problems: options left and right are included in a
> >> codebase originally not designed for it
> >> that's fine for developers because that way you can start every
> >> few years from scratch with remove, re-write and cleanup but it
> >> hardly gains anything for the users
> > In fact, since developers can fix bug more easily with a code that is
> > clean, it benefits to users as well.
> you ignore the bugs of missing functions which will be the first
> so you postponed the work only
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.
> >> a smart re-write is using the benefit knowing what all sort of options,
> >> functions and configurations where added all the time before and
> >> organize the codebase to implement it in a better, more generic way
> >> with sane (API) interfaces
> > Perfect, so are you leading the way, or do you continue to tell to
> > people how to make a smart rewrite without being more specific and
> > without putting any efforts?
> my effort is try to prevent thousands of bugreports
Thousands ? I think you are exaggerating. Hyperbolic statements do not
> did you realize that in this thread it was even suggested
> to completly remove the yum command over the long even
> if it is only a symlink?
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.
People who want the old yum can keep it alive, the others can use the
> >> throwing all away, start with a minimum and be proud
> >> it's faster and cleaner is only a short term solution
> > You still didn't answer to the question I asked.
> > How long do you want compatibility be kept, and what compatibility
> > exactly ?
[snip of yum help]
That's neither the answer to :
- how long
More information about the devel