Switching to RPMv4


we are about to swtich RPM to version 4.

This is a companion discussion topic for the original entry at https://www.openmandriva.org/en/news/article/switching-to-rpmv4

Ok. What does it means? Are we not going to use urpmi any more? What about MCC or OMCC? I use to do,

$ urpmi --auto-update

to keep the system up to date, is this not going to work any more?


Pinging @bero @ngompa @tpg @fedya for previous question.

still using urpmi for 3.0
cooker already on dnf

I have to rebuild all packages contained in my cooker personal repository?

First - I would like to thank everyone involved in this work, great job guys.
Second - ABF is it already working? I tried to build a package today, which was well built a month ago, but today rebuild failed. Do we have to apply any changes?
Third - Does this mean a complete abandonment of “urpmi” in OMV 4 for “dnf”. Or will it happen like in a similar Mageia distribution, where both urpmi and dnf are still available?

This is from todays TC-meeting @ #openmandriva-cooker on Freenode IRC.

Meeting logs from todays TC-meeting.

Perhaps that will answer some questions. Developers are still working on this but it is getting close to being functional.

Nothing changes in Lx 3 the changes are all focused on Lx 4.0/Cooker.

Edit: for some reason Discourse does not publish the meeting logs verbatim so I’m going to provide a link to the entire log. (Or I didn’t do it correctly).

1 Like

urpmi --auto-update will keep working – we’re adding a wrapper script that will forward urpmi command lines to dnf.
Probably the only change you’ll notice is that it will be faster and less buggy.

Not to say I’m already missing urpmi, let me ask if we’ll still count on something like OMCC?

OpenMandriva Control Center aka MCC aka drakconf is like all drak tools going to eventually be replaced. The code is to old, to bad, and to much written in perl and is very difficult to impossible to keep maintaining.

That does not mean they are just tossed away. The goal is to rewrite or right anew applications with same or similar functionality. The packages currently in Lx 3 ‘oma-welcome’ and ‘om-control-center’ are a beginning in this direction. As example ‘om-control-center’ is hoped to develop into a replacement for ‘drakconf’ When those of you that care about these application and tools sense that developers are working on the replacements then you really need to get involved in discussion and testing. For one so developers know better what you the users want. Some things will be similar, some could be better than before, and some will be discarded. But the code will be modern and easy to maintain. Overall the goal is to make something better for all.

Note: ‘om-control-center’ is closer to pre-alpha than a finished product and is currently available strictly for user testing and comment. ‘oma-welcome’ is closer to a finished product but may or may not have some room for improvement. (Meaning I haven’t really tested it throughly recently).

One thing I’m aware of a need for is a replacement for userdrak or kuser. KUser is dead upstream and I don’t know of a replacement for it at kde.org. So we may want to be sure we get a new GUI tool for user and group management. I don’t care if it is still called userdrak as long as the code gets rewritten.


Thanks for explanation @ben79 :slight_smile:


Also to start learning about dnf one can do Internet search of “Fedora dnf” and will come up with this among other articles.


lil info… there be already urpmi sources for rpmv4, old must not meant to be bad, but they are be existent for working further with rpm v4 and urpmi. I guess, it’s really possible to roll back to the more older sources of urpmi where works perfectly with rpm v.4…
just as hint … , we don’t need dnf , it take only us urpmi and rpmdrake away, the dnf change the “face” of our …driva totally, urpmi and drakrpm/rpmdrake is one of the basic parts of our distribution.

Huh, this is not something that is going to happen in the future it already has happened. This is changed for good in Cooker. And as goes Cooker so goes OpenMandriva Lx. This is over, done.

Carefully note: Nowhere in the above paragraph did I express an opinion as to whether I think this is either good or bad.

Carefully note: This was not decided by me, I am merely reporting. This was a developer only decision and the developers were unanimous in their decision.

well, then can i also go to fedora… it’s then the same…
and more stable and more developer…
because it no longer stands out from other distributions…