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.
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.
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.
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:
software X is monolith
upstream dedices to split X into smaller packages to speed up release process
OMV maintaier needs to adapt above into RPM spec files
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:
Package is build for 3.0 tree
CI bot runs first a clean 3.0 ISO environent and runs update of that package
CI bot runs clean 3.01 ISO environent and runs update of that package
CI bot runs clean 3.02 ISO environent and runs update of that package
CI bot runs clean 3.03 ISO environent and runs update of that package
etc
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.
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”).
any chance we can make you stay?
