Description of problem: I had a couple of Mga6 systems which I finally got around to doing the massive update on (had not updated since about April). I ran urpmi.update -a on both first. One machine went fine, the other one "blew up" It started out with about 700 updates scheduled, and managed to complete about 50 of them, when It began complaining about masses of conflicts (pachage A needed for installed package B, or lib64A needed for installed package B). After a couple of retries which never got anywhere (installed nothing extra) I finally picked a random one of the complaint lines, and tried installing that one package complained about. (eg package A above) Then I tried urpmi --auto-select --update again, and now about 40 new packages were installed. I tried another time to install one of the complaining packages, and then the auto-select and again another 40 packages were installed. (I was now down to about 500 remaining. I finally chose about 5 of the complaining packages to install at random, (all of which installed without problem) and suddenly all of the remaining packages in the update installed. I am really sorry that I did not make a copy of all the problems so cannot be more specific, but this seems to indicate some serious problem in the urpmi selection algorithm, it is either not grouping the installs properly, or something is going wrong inside urpmi. The only other weirdness is that it left about 80 packages as orphans which did not happen on the other machine. So something seems to be really weird with urpmi on this one machine. Let me know if there is some log on this machine that I could send you so you could figure out what is going wrong in urpmi.
Created attachment 10270 [details] List of urpmi attempts to install updates. This is the contents of journalctl -b|grep -i rpm Note the successive failures to install stuff, and you can also see the random items I installed with loosened up the logjam slightly, until finally it completed (with many orphans listed afterwards). Is there some way I can show you the list of orphans that were left over?
Created attachment 10271 [details] List of orphans left after update I found urpmq --auto-orphans Here is the output of that command after the upgrade.
(In reply to w unruh from comment #0) > Description of problem: I had a couple of Mga6 systems which I finally got > around to doing the massive update on (had not updated since about April). > I ran urpmi.update -a on both first. One machine went fine, the other one > "blew up" It started out with about 700 updates scheduled, and managed to > complete about 50 of them, when It began complaining about masses of > conflicts (pachage A needed for installed package B, or lib64A needed for > installed package B). After a couple of retries which never got anywhere > (installed nothing extra) I finally picked a random one of the complaint > lines, and tried installing that one package complained about. (eg package A > above) Then I tried > urpmi --auto-select --update > again, and now about 40 new packages were installed. I tried another time to > install one of the complaining packages, and then the auto-select and again > another 40 packages were installed. (I was now down to about 500 remaining. > I finally chose about 5 of the complaining packages to install at random, > (all of which installed without problem) and suddenly all of the remaining > packages in the update installed. > AFAIK, that is caused by packages that need one another not ending up in the same transaction. Default transaction size is 50 at the moment. If you have enough disk space to download all the updates before installing them, then adding --split-length 0 to your urpmi command should fix this problem (that'll keep urpmi from splitting the operation in small transactions)
Summary: urpmi --auto-select --update reports does not update most files but reports conflicts instead => Default transaction size is too small for very large update (Was: urpmi --auto-select --update reports does not update most files but reports conflicts instead)Assignee: bugsquad => mageiatoolsSource RPM: urpmi? => urpmiCC: (none) => marja11, thierry.vignaud
Mageia 6 changed to end-of-life (EOL) status on 2019-09-30. It is no longer maintained, which means that it will not receive any further security or bug fix updates. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Mageia version. Bug Reporter: Thank you for reporting this issue and we are sorry that we weren't able to fix it before Mageia 6's end of life. If you are able to reproduce it against a later version of Mageia, you are encouraged to click on "Version" and change it against that version of Mageia. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Mageia release includes newer upstream software that fixes bugs or makes them obsolete. If you would like to help fixing bugs in the future, don't hesitate to join the packager team via our mentoring program [1] or join the teams that fit you most [2]. [1] https://wiki.mageia.org/en/Becoming_a_Mageia_Packager [2] http://www.mageia.org/contribute/ Best regards, Aurélien Bugsquad Team
Resolution: (none) => OLDStatus: NEW => RESOLVEDCC: (none) => ouaurelien