Taking a break from OpenMandriva

For a number of reasons some of which are discussed here I’m needing to take a break from activity regarding OpenMandriva.

At this point I don’t know what I will decide to do over the long term.

Moderators: I’m guessing whether this is the correct category for this post.

Good luck and hope you will get back to us soon.

That’s no good at all :frowning: any chance we can make you stay?

Maybe just wait a little, generally between catholic Christmas and orthodox Christmas, there is a lower activity, and furthermore the forum had some problems due to migration recently…

Thanks @TPG and @raphael. It isn’t a question of lack of activity which I expect this time of year.

The problem is are there other people who believe our package checking system is broken and want to devote some of our time and resources to fixing it?

I think it is badly broken and must be fixed but I seem to be a group of 1 with this view. So that implies that I’m not a good fit for this group.

1 Like

You are needed here, nobody wants you out of the business

Thanks for the comment. We’ll see where this all goes. As matters stand I am taking a break at least from testing packages.

Hello ben79,

I'd like to talk to you about the problems of "upgrading" in OpenMandriva Lx and make clear to you that you are not alone with what you have observed. I'm an ordinary OpenMandriva Lx user; and only very recently I've signed in into the OpenMandriva Forum, not yet having contributed anything. I've installed OpenMandriva Lx 3.01 (Einsteinium) in December 21, 2016, mostly for being interested in LLVM/clang, but after installation I've not used the system intensively until November 2017 due to other priorities and lack of time. I'm a long-time user of Linux, using it with a certain intensity approximately since 2007. For the reasons above, only in November 2017 I began to figure out the possibilities of updating and upgrading OpenMandriva Lx. The first tool I found for that was RPMDrake which offered to me an upgrade of more that 2500 packages which I didn't accept, knowing that this could put the system at risk. Then I found Discover offering an upgrade to me with more than 2200 packages what I also rejected. At last I found urpmi and rpm on the command line. After reading through the manpages I chose

urpmi --buildrequires  --auto-select

(which I later refined to  urpmi  --buildrequires  --strict-arch  --auto-select)

which  offered an upgrade of  1340  packages to me  which  I  accepted.  All  in  all,  it took about  seven and a half  hours  and  it  was  amazing.
Somewhere in the middle of that process I had a problem with a package named messagelib-3:17.04.0-3.2015.0.x86_64 (or similar) with which urpmi faced a package conflict that it couldn't resolve, so I had to help urpmi by uninstalling that package manually; and afterwards I let urpmi continue the rest of the upgrading process by simply repeating the command above. It went on smoothely until the end. After the first reboot, the system was not as it was before. The console level was not directly accessible anymore (solely the X window system level became accessible), all SysRq shortcuts were taken away and a tight security became apparent. sddm appeared in a new fashion, now giving a choice of desktops and an X terminal window as options. At that time Plasma and LXQt were still fully functional.
From that time onwards, now regularly using OpenMandriva Lx, I began to realize that I had a lot of orphan packages on my system. This must have been around the second week of December 2017. I think these were approximately 480 packages. So I decided to get rid of them, doing

urpme --auto-orphans

Since then, I haven't seen my Plasma desktop anymore. Of course, I've tried to figure out what the problem was. At that time some KDE and Qt packages were object of an upgrading from Qt 5.6.7 (or 5.6) to 5.8.0, I guess. Some of the Qt 5.6.7 (or 5.6) packages should not have been erased because the upgrading process was not completed for all components of Plasma. Later I've lost LXQt as well while trying out things with the system. Meanwhile I reside on Openbox; and I've customised it for my needs. But that is not the essence of the story.

Now: Is the urpm package management suite to blame for what I saw?

My stunning answer is "No!" And here we come to a crucial point:

The best package manager of the world cannot fulfil its job in a good manner as long as the package-underlying directory tree structure remains archaic.

What must the package-underlying directory tree structure do?

The package-underlying directory tree structure must allow to install a package of the same sort in different versions.

This is so, because during an upgrading process usually not all packages are upgraded at once, but mostly only a bunch of them. Therefore there must be the possibility that several packages of the same sort with different versions can reside on the system. If upgrading processes would not allow packages of the same sort with different versions to reside on the system, the upgrading processes would become very bumpy.  During recent weeks I had the chance to see as an example that urpmi had to overwrite parts of lib64icudata57 for installing lib64icudata60, as far as I remember, which was caused by the directory tree structure and not by urpmi. Such overwritings are a matter of stability for the system. If we take a look at Slackware and its derivates for example, we find that all directories that reside in /usr/share begin with a package name and version number while in Openmandriva Lx only a very small number of subdirectories of /usr/share have a version number appended to the name. The same is valid for directories residing in /usr/doc there.  So overwritings in Slackware and its derivates could only occur in other directories like /var and /etc. Even in /etc config files get an appendix .new there, if an older version is already on the system. Thus Slackware and its derivates are mostly quite stable. I'm aware that you cannot be blamed personally for the problems. You have inherited the system from the Mandriva guys; and they in turn have inherited it from the Mandrake guys. And the first release of Mandrake was in July 1998. At that time there were no demands towards the operating system to run a semi-rolling release model, as you practice it today with OpenMandriva Lx. And regarding this, nobody has ever said that you have to keep the directory tree structure that you inherited from your predecessors forever!
Is this a difficult problem? It depends on how thorough the changes become that you intend to apply on the system. For example: if you want to give version numbers to the subdirectories of /usr/share and /usr/doc then you have to change the rules for package making! To add an appendix .new to config files that reside in /etc is also not difficult and would fall into the same category. I have no idea what container technologies could offer to the OpenMandriva team in this sense, but perhaps others can help you with that topic.

You are not alone. And we all face those problems. It's something that can be resolved. I hope that these hints will help you.

With kind regards,

A. A. R.

1 Like

Thanks for the reply.

Some of the problems you allude to are due to how OpenMandriva is/isn’t governed. There really isn’t anyone in charge and there really aren’t any written policies and guidelines for package maintainers and developers to follow. So it is all to easy for well meaning people to “forget” or “ignore” things that have been discussed and agreed upon in our TC-meetings. This happens so much that it is normal.

Pretty much anyone involved with OpenMandriva can come up with a list of things we thought had been agreed on that never got done.

Edit: Let me clarify something. The people who are involved with OpenMandriva do excellent work. My point is that I disagree whether we are devoting as much of our resources to package/rpm QA as we could and whether we are as organized about package/rpm QA as we could be with our current resources.

Edit-2: Clarifying some more. This is not meant as a criticism of any individual. My comments about “no one is really in charge” are not directed in any way to our President who does a massive amount of excellent work for this disto. It is the overall structure of governance that is lacking. As far as what to do about it I am asking not telling.

This baffles me as I would first look for the latest version and reinstall. And I mean this for any distro, Fedora, openSUSE, Linux Mint, any of them.

Some OpenMandriva history. The OpenMandriva current versions are Lx 2014, and Lx 3. Officially 2014 is unsupported when Lx 4 is released but as a practical matter is is unsupported now. That is a function of being a Community distro of all volunteer contributors and frankly not having IMO enough contributors to do everything we would like to do.

The designations of Lx 3.0x are spins which are all Lx 3 with most recent packages as of the time of that particular spin. And OpenMandriva does tell users to use the most recent spin. In other words after Lx 3.02 has been released install Lx 3.02 NOT Lx 3.01. I doubt if someone today installed Lx 3.0 (the original version) and tried to update if it would be possible. Whether it should be possible I’ll leave to others to discuss.

May be, I didn't feel that something important had passed me. I'm not that type of guy who runs to obtain every minor release to install it.
Haven't you got any templates of scripts to build packages that could serve for the community as landmarks of orientation so that the directory tree structure of OpenMandriva Lx could become improved? Other improvements could also be brought forward in such way. Perhaps, this would be a more practical approach than just making TC-meeting decisions.

There were some ideas how to improve QA situation. Problem is not related to “templates”.
Maybe it is not clear but our build system does have testing functionality and it does test each rpm if it installs. We do have also a daily check of repository integrity.

Problem is deeper and lies when upstream decides to split/conflicts on some software.
Here is an example:

  1. software X is monolith
  2. upstream dedices to split X into smaller packages to speed up release process
  3. OMV maintaier needs to adapt above into RPM spec files
  4. Here is the step where bad things may happen

Anyways one idea to improve QA was to set up a couple of CI bots. Proposed flow was this:

  1. Package is build for 3.0 tree
  2. CI bot runs first a clean 3.0 ISO environent and runs update of that package
  3. CI bot runs clean 3.01 ISO environent and runs update of that package
  4. CI bot runs clean 3.02 ISO environent and runs update of that package
  5. CI bot runs clean 3.03 ISO environent and runs update of that package
    If one of above fails then package was rejected. On each step CI should check for urpmi errors (file conflicts, package conflicts, anything that stops clean and smooth update).

Unfortunately there were none who stepped up and took the task to set up CI and whole flow.


Thanks @TPG for responding to this. Some great points to improve QA.

Full Disclosure: At my knowledge level I don’t know of anything that might be wrong with directory tree structure. Also I don’t feel qualified to weigh in on this particular issue.

I’m sort of back to doing some things but not yet back to testing packages or fully engaged with Issue Tracker. I have a lot of things in personal and family life that need my time at the moment. Estimate 2-3 weeks before I’m back at least to Issue Tracker and hopefully also to package testing.


It is the first time I see a failure at test stage on ABF. Something are changing? :slight_smile:

Yes, I’ve added some fixes that improved testing in ABF. On next week I’ll add more testing.

1 Like

Thanks for responses everyone. There are some good things in the works for package testing. for that I thank @TPG and @Colin (aka: “The Grand Pooh-Bah”).

So I’m closing this. Am I back? :fearful:

1 Like

You MUST be back :slight_smile:

1 Like