| Summary: | urpmi --auto-update find 42 pkgs to install while dnf --auto-refresh upgrade finds none | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | peter lawford <petlaw726> |
| Component: | RPM Packages | Assignee: | Mageia Bug Squad <bugsquad> |
| Status: | RESOLVED INVALID | QA Contact: | |
| Severity: | normal | ||
| Priority: | Normal | CC: | davidwhodgins, fri, lewyssmith, ouaurelien |
| Version: | 8 | ||
| Target Milestone: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | CVE: | ||
| Status comment: | |||
| Attachments: | urpmi/dnf tests | ||
|
Description
peter lawford
2021-03-31 00:07:34 CEST
Just trying this: $ sudo urpmi --auto-update --test ... Estynnir 264MB o becynnau. [264Mb will be fetched] Parhau i osod 33 o becynnau? (Y/n) n [Continue to install 33 pkgs] $ sudo dnf --refresh upgrade ... Transaction Summary Install 2 Packages Upgrade 32 Packages Total download size: 265 M Is this ok [y/N]: n Looks pretty similar to me. I hope you are not mixing urpmi and dnf: it is recommended NOT to do so. Is this complaint a recurring one, or was this example one-off? What made you try both methods? CC:
(none) =>
lewyssmith DNF unreliable? Will wait for updates and will test this on the weekend. CC:
(none) =>
ouaurelien (In reply to Lewis Smith from comment #1) > Just trying this: > > $ sudo urpmi --auto-update --test > ... > Estynnir 264MB o becynnau. [264Mb will be fetched] > Parhau i osod 33 o becynnau? (Y/n) n [Continue to install 33 pkgs] > > $ sudo dnf --refresh upgrade > ... > Transaction Summary > Install 2 Packages > Upgrade 32 Packages > Total download size: 265 M > Is this ok [y/N]: n > > Looks pretty similar to me. > > I hope you are not mixing urpmi and dnf: it is recommended NOT to do so. when I do updates, I begin to run dnf --refresh upgrade and I finish with: urpmi --auto-update > > Is this complaint a recurring one, or was this example one-off? this happens very rarely > What made you try both methods? because dnf adress not only to mageia repos, but also to non mageia repos (google chrome, skype, opera...) while urpmi doesn't Regarding DNF + urpmi potential problem: https://wiki.mageia.org/en/Using_DNF#Warning_about_orphans_mechanisms Apart from that, should we add more information or warnings? I believe it should be OK if you don not use automatic orphan removal by any of them. CC:
(none) =>
fri (In reply to peter lawford from comment #3) > because dnf adress not only to mageia repos, but also to non mageia repos > (google chrome, skype, opera...) while urpmi doesn't # urpmq --list-url|head -n 1 google-earth http://dl.google.com/linux/earth/rpm/stable/x86_64 If they have rpm repository, urpmi can handle it . In /etc/urpmi/urpmi.cfg, I have google-earth http://dl.google.com/linux/earth/rpm/stable/x86_64 { key-ids: 7fac5991,d38b4796 update } That was added using urpmi.addmedia, and the keys downloaded from one of the pgp public key servers, and then imported using rpmkeys. Mixing urpmi and dnf is not a good idea. CC:
(none) =>
davidwhodgins @Peter
> when I do updates, I begin to run
> dnf --refresh upgrade
> and I finish with:
> urpmi --auto-update
Curious, because if the first one (DNF) does its job, the second (urpmi) should have nothing left to do. Yet in the example you give at the beginning, the order was reversed. The first urpmi update (but you replied 'N') somehow thinks it happened, so DNF then found nothing to do. Puzzle.
Also, in your example, why did you reply 'N' to the first urpmi update list, when you would have normally replied 'Y' - unless you suspected that DNF would then report no updates. OTOH in a normal situation, you would have accepted (Y) the urpmi updates and then tried DNF for any non-Mageia ones.
Created attachment 12561 [details]
urpmi/dnf tests
For understand:
Did tests:
1) urpmi: 81 packages to updates/install with urpmi --auto-update command with core/nonfree/tainted repo.
2) Same test with dnf
# dnf makecache <=== this is mandatory to do before asking to look for update as the timer should not be triggered since a while.
# dnf upgrade
81 packages. Same names.
See attached text.
Normally there is a dnf-makecache.timer that refreshs dnf/yum repositories.
$ systemctl status dnf-makecache.timer
● dnf-makecache.timer - dnf makecache --timer
Loaded: loaded (/usr/lib/systemd/system/dnf-makecache.timer; enabled; vendor preset: enabled)
Active: active (waiting) since Sat 2021-04-03 16:32:45 CEST; 10min ago
Trigger: Sat 2021-04-03 16:44:12 CEST; 44s left
Triggers: ● dnf-makecache.service
avril 03 16:32:45 localhost systemd[1]: Started dnf makecache --timer.
This timer does not triggers at boot but 5 minutes later after logon...
Also note that by default, only $ARCHcore/release and $ARCH/core/updates are enabled in dnf configuration (where $ARCH = x86_64 or i586 depending how you installed Mageia). You have to edit several files in /etc/yum.repo.d/... Note also that both packages managers use different methods to look for dependencies. Sometimes, dnf wants to install more packages, sometimes it is urpmi... Note also urpmi uses $MIRRORLIST to look for best bandwidth and nearest mirror. dnf uses same but both can choose different mirror at same time! Some mirrors chosen can be out-of-date... Resolution:
(none) =>
INVALID Note also urpmi uses $MIRRORLIST to look for best bandwidth and nearest mirror. dnf uses same but both can choose different mirror at same time! Some mirrors chosen can be out-of-date... (Oups, too quick.) that's why this can happen. Not a bug. Perhaps, try to tell urpmi to use a unique mirror like http://ftp.free.fr/mirrors/mageia.org/distrib And do the same for DNF under /etc/yum.repo.d/ files. mageia-x86_64.repo : [mageia-x86_64] name=Mageia $releasever - x86_64 ## Uncomment following: baseurl=http://ftp.free.fr/mirrors/mageia.org/distrib/8/x86_64/media/core/release/ #metalink=https://mirrors.mageia.org/metalink?distrib=mageia-$releasever&arch=x86_64§ion=core&repo=release Comment: #mirrorlist=https://www.mageia.org/mirrorlist/?release=$releasever&arch=x86_64§ion=core&repo=release gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-Mageia fastestmirror=1 enabled=1 Feel free to reopen if this occurs again with making sure both package manager use same mirror. |