Should work with 'urpmi gnucash --excludemedia Backports'.

--excludemedia is a probable workaround.

But having backport enabled should not make urpmi blind of what is available in release...

I'd say it's how urpmi works. Select newest pkg from available media if multiple versions exists with the same name. Urpmi doesn't know that same and specific EVRD is also wanted for reqs than was given for the pkg to be installed. Unless deps with specific EVRD are also passed to urpmi via cmd.

I have had no problems ever to install something from Core Release either by excluding unwanted media with '--excludemedia Update' or by searching only from Core Release with '--media Release'

What if this gnucash 4.11 now in backports testing, was instead put in updates.

A user that then install gnucash would land in this problem, I guess?

Dependencies are in release media, so probably simplest workaround is then to exclude/disable updates repo, install gnucash, and then update.  Normal users would not know that, especially with a bogus error message to "help"...


Anyway at least the error message is wrong or strongly misleading; "unsatisfied lib64gnucash0[== 4.4-2.mga8]", while it is even in the release media, which is enabled.

urpmi is working as it should.  You shouldn't just leave backports enabled.  Only enable it momentarily when installing something from backports, then disable it.

Status: NEW => RESOLVED
Resolution: (none) => INVALID

My fear is if urpmi have this quirk also for other repos?

(In reply to Morgan Leijström from comment #4)
> What if this gnucash 4.11 now in backports testing, was instead put in
> updates.
> 
> A user that then install gnucash would land in this problem, I guess?


And anyway there is a bug:

> the error message is wrong or strongly misleading;
> "unsatisfied lib64gnucash0[== 4.4-2.mga8]", while it is even in the release
> media, which is enabled.

It sounds similar to bug 2317, which was fixed to allow updates to require
packages from release repo. Prior to that being fixed every update had to
include a copy of any unchanged packages it required in the update.

So a regular update shouldn't be affected.

CC: (none) => davidwhodgins

Anyway, the cause is improper use of backports.

Proper use is to enable the backports repo, install the desired packages,
and then disable the backports repo.

(In reply to Dave Hodgins from comment #8)
> Anyway, the cause is improper use of backports.
>
> Proper use is to enable the backports repo, install the desired packages,
> and then disable the backports repo.

If you are using urpmi to install backports, the proper use is not to enable the backports media at all, but to use the --search-media option, e.g.

  urpmi --search-media 'Backports Testing' gnucash

CC: (none) => mageia

The cause of Morgan's original issue can be seen by using the urpmi --debug option:

[root@localhost ~]# urpmi  --debug --test gnucash-4.4-2.mga8
getting lock on urpmi
parsing: /etc/urpmi/mediacfg.d/Official-8-x86_64
loading mirrors cache
using mirror http://www.mirrorservice.org/sites/mageia.org/pub/mageia/distrib/8/x86_64
using mirror http://www.mirrorservice.org/sites/mageia.org/pub/mageia/distrib/8/x86_64
using mirror http://www.mirrorservice.org/sites/mageia.org/pub/mageia/distrib/8/x86_64
using mirror http://www.mirrorservice.org/sites/mageia.org/pub/mageia/distrib/8/x86_64
using mirror http://www.mirrorservice.org/sites/mageia.org/pub/mageia/distrib/8/x86_64
using mirror http://www.mirrorservice.org/sites/mageia.org/pub/mageia/distrib/8/x86_64
examining synthesis file [/var/lib/urpmi/Core Release (distrib1)/synthesis.hdlist.cz]
examining synthesis file [/var/lib/urpmi/Core Updates (distrib3)/synthesis.hdlist.cz]
examining synthesis file [/var/lib/urpmi/Core Backports (distrib7)/synthesis.hdlist.cz]
examining synthesis file [/var/lib/urpmi/Core Backports Testing (distrib9)/synthesis.hdlist.cz]
examining synthesis file [/var/lib/urpmi/Nonfree Release (distrib11)/synthesis.hdlist.cz]
examining synthesis file [/var/lib/urpmi/Nonfree Updates (distrib13)/synthesis.hdlist.cz]
getting exclusive lock on rpm
search_packages: found gnucash-4.4-2.mga8.x86_64 matching gnucash-4.4-2.mga8
found package(s): gnucash-4.4-2.mga8.x86_64
opening rpmdb (root=, write=)
selecting gnucash-4.4-2.mga8.x86_64
requiring guile3.0,lib64gnucash0[== 4.4-2.mga8],libboost_program_options.so.1.75.0()(64bit),libboost_regex.so.1.75.0()(64bit),libdbi-drivers-dbd-sqlite3,libgnc-app-utils.so()(64bit),libgnc-backend-sql.so()(64bit),libgnc-backend-xml-utils.so()(64bit),libgnc-core-utils.so()(64bit),libgnc-engine.so()(64bit),libgnc-generic-import.so()(64bit),libgnc-gnome.so()(64bit),libgnc-module.so()(64bit),libgnucash-guile.so()(64bit),libguile-3.0.so.1()(64bit),libguile-3.0.so.1(GUILE_2.0)(64bit),perl(Date::Manip),slib for gnucash-4.4-2.mga8.x86_64
chosen lib64gnucash0-4.11-1.mga8.x86_64 for libgnc-module.so()(64bit)
selecting lib64gnucash0-4.11-1.mga8.x86_64

Because lib64gnucash0-4.11-1.mga8.x86_64 satisfies the unversioned dependency "libgnc-module.so()(64bit)", urpmi can happily select it to meet that dependency. But once urpmi has done that, it can't then select lib64gnucash0-4.4-2.mga8.x86_64 to satisfy the hard-versioned dependency "lib64gnucash0[== 4.4-2.mga8]".

Yes, the error message is not helpful in this case, but that's often the way with conflicting dependencies.

So in the backport gnucash should have had a version specific requires for
the lib{64}gnucash0 package.

Thank you for the explanations.

It is probably generally good it selects latest version when there is no restriction.  I was in the thinking it should evaluate other selections if the initial choice do not lead to a full solution - not just give up.  I could dream, but not code... :)

How do dnf compare in this situation?

(In reply to Martin Whitaker from comment #9)
> If you are using urpmi to install backports, the proper use is not to enable
> the backports media at all, but to use the --search-media option, e.g.
> 
>   urpmi --search-media 'Backports Testing' gnucash

Cool :)   Entered:

https://wiki.mageia.org/en/URPMI#Install_from_non_enabled_media.2C_i.e_Backports

For a non-enabled repository, the meta data will only show what was available when the repositories were set up, whether that's from the system installation or from switching mirrors.

To update the metadata for both enabled and non-enabled repositories, I use
"urpmi.update e". The letter e has no special significance to urpmi. It works
because the words core, nonfree, and tainted, all have the letter e in them.

:)
added to https://wiki.mageia.org/en/URPMI#urpmi.update