It seems dnfdragora doesn't respect repository priorities

[L-U-T-i]

It is very annoying for updates.

I've rebuilt Fedora packages for CentOS 8, and everything seems to work good for me, but list of updates.

I have EPEL repo with priority 50 and EPEL Playground repo with priority 55, because I prefer to have packages from EPEL (not Playground) installed.

"dnf update" shows no updates (as expected on already updated system), while I see plenty of packages to be updated (EPEL Playground packages over EPEL ones - with the same versions / releases...).

[anaselli]

Hmm i didn't know such a feature, i'd expected priority to be related to download not for info and install. Is that to be demanded to client/hmi or to dnf-daemon? Any doc/link to point me to?

[anaselli]

@Conan-Kudo can you help me in here?

[Conan-Kudo]

the repo priorities thing comes from DNF itself, I'm confused why dnfdaemon wouldn't respect that, since we leave all that to DNF: https://dnf.readthedocs.io/en/latest/conf_ref.html#repo-priority-label

@j-mracek or @dmach, could you comment?

[L-U-T-i]

As written, DNF does respect it (doesn't offer me any updates on a freshly updated system), but something (can not judge weather it is dnf-daemon or dnfdragora, but it is manifested in dnfdragora - so I've filled the issue there) cause exactly the same versions (and releases) from EPEL Playground repo (with a priority 55 - so lower than EPEL repo with priority 50) to appear on the list of updates (to update the same packages of EPEL repo)...

Could it be that dnfdaemon launches dnf without any plugins? Or, is it just this one which seems not to be active...?

[anaselli]

We need to investigate more here. I'm not sure i understood.
So priority should just give the priority to a repo when the same package is exposed, I mean IIUC if there is an update or a not installed package requested then dnf gives the one from the repo with lower number of priority value.

But the reporter seems to say that the system is updated.
That is odd, so probably the problem (or the feature) is really to address to dnfdragora, since for an old issue for which it did not show updates (or new packaged as updates) from external repos we added that an update is update or new package.

[anaselli]

No i can't get it. why dnf should not show anything if you have new updates that comes only from the lower priority repository?

If there is more than one candidate package for a particular operation, the one from a repo with the lowest priority value is picked, possibly despite being less convenient otherwise (e.g. by being a lower version).

more than one candidate and not just one from a repo. Or do I have misunderstood anything?
I'm not saying we are wrong, i'm just trying to understand :)

[Conan-Kudo]

@L-U-T-i priorities do not affect searching and indexing packages, only selection of packages for transactions (e.g. installation).

[L-U-T-i]

That's what I get:

I have for example amavis-2.12.0-9.el8.noarch.rpm from EPEL repo installed, but dnfdragora wants to update it to amavis-2.12.0-9.epel8.playground.noarch.rpm. Maybe because 9.epel8.playground is considered higher than 9.el8? But, it is the same version/release, and priority settings as above help me with dnf to not consider it as an update. So, I'd say dnfdaemon or dnfdragora does something wrong... Or, at least not exactly as dnf (just GUI), what is not OK anyway, or?

[L-U-T-i]

And, while making this screenshot, I've noticed dnfdragora window height at 2.1.0 can not be reduced below as on my screenshot (it would be convenient in my case to have it smaller - so bigger part of a terminal window would be visible...). Can this be reverted back to as in 2.0.4?

[anaselli]

Well that package is certainly from dnfdaemon, but you're right 2.12.0-9.el8 is lower than 2.12.0-9.epel8.playground.1 while Version is the same, Release (as you can see in your picture) is 9.epel8.playground.1, a versioning example here.
So that package is ready for update/upgrade for dnfdragora, don't know what to say more.

Concerning windows i assume you're using gtk one, so i'd expect such a limitation is due to libyui-gtk not dnfdragora, here below my Qt one:

[L-U-T-i]

I'm not sure if "9.el8" release shall be considered as lower than "9.epel8.playground"? "el8" and "epel8.playground" are added through a "dist" macro, so numerical part of release is in both cases just 9 (= equal).

If it would be as you say, also a "dnf update" command should provide the package upgrades, or?

In any case, I would expect to get exactly the same "results" (updated packages installed at the end) if I launch "dnf update" in shell / terminal or if I launch dnfdragora 2 -> updates -> select all...

BTW - I started to notice this behavior just recently (with dnfdragora 2.0.0). Older dnfdragora 1.1 didn't "push" EPEL Playground! Also the latest yumex-dnf doesn't, so I guess something went wrong with the last versions of dnfdragora...

I've made a test now with different versions of dnfdragora and just the latest dnfdaemon. So, looking at the results (screenshots) it is obvious it is dnfdragora >= 2 to be blamed by my opinion (dnfdaemon is the same also for yumex-dnf which performs as expected, as well as dnfdragora 1.1).

About the window height, I'm not sure I understand how libyui-gtk would force such a min. height for dnfdragora 2.1.0, but not for all other windows (as dnfdragora 2.0.4 / 2.0.0 / 1.1 or yumex-dnf)?! I suspect there is something else (as a min. number of rows visible or so) changed since dnfdragora 2.1.0 and 2.0.4...

Screenshots:

[anaselli]

I'm not sure if "9.el8" release shall be considered as lower than "9.epel8.playground"? "el8" and "epel8.playground" are added through a "dist" macro, so numerical part of release is in both cases just 9 (= equal).

But it is. %dist macro is just for packaging is not for querying, At the time Mageia started upgrade from mandriva was supported and that was reached also because package-Version-Release.mga1 was higher than package-Version-Release.mdvX.

If it would be as you say, also a "dnf update" command should provide the package upgrades, or?

In any case, I would expect to get exactly the same "results" (updated packages installed at the end) if I launch "dnf update" in shell / terminal or if I launch dnfdragora 2 -> updates -> select all...

Well i don't know what dnf does, i know what yumex-dnf was since i started from that code, but as i said in my previous comments i added also package to install as updates to fix an issue in which (and here i'm quite sure yumex-dnf failed at the time i started) dnfdragora didn't show updates from external repositories such as skype, mega etc. and that because they are often if not always new versions. So it's probably that the different behavior you noticed.
But i cannot evaluate if a pacakge is the same as the one installed or a new one if their releases are different, certainly both packager are different and built differently.
For instance in mageia we have two official repositories core and tainted, from the first you could get

• avidemux-cli-2.7.6-2.mga8.x86_64.rpm

while from the latter

• avidemux-cli-2.7.6-2.mga8.tainted.x86_64.rpm

They are same release but one has different content, built differently etc... for instance not free code, patent etc..
As you can see mageia plays with release to grant upgrades, and users have it for free by enabling the repo... and note that both repos are officially maintained by the distro.
So if i remove this feature i will be wrong for many users.
Maybe it could be disabled by an option that allows to show pure updates, but that requires to write code, i'm always ready to get patches from users of course :D

[anaselli]

About the window height, I'm not sure I understand how libyui-gtk would force such a min. height for dnfdragora 2.1.0, but not for all other windows (as dnfdragora 2.0.4 / 2.0.0 / 1.1 or yumex-dnf)?! I suspect there is something else (as a min. number of rows visible or so) changed since dnfdragora 2.1.0 and 2.0.4...

Maybe you're right, but i don't seem to have used createMinSize for main dialog, i will check libyui-gtk behavior as soon as i can, but since it isn't manatool core but suse (should be really, since it does not provide changes there), i do that with lower priority, sorry.

[anaselli]

@L-U-T-i may ask you a test?
I made a search and i think i did that change here.
So since i can't reproduce that now, i need to install fedora and add your repos, or find a test case here, you could do a test for me. I mean You could change a line into dnfdragora/ui.py.

diff --git a/dnfdragora/ui.py b/dnfdragora/ui.py
index bbf6d69..5497af3 100644
--- a/dnfdragora/ui.py
+++ b/dnfdragora/ui.py
@@ -1885,7 +1885,7 @@ class mainGui(dnfdragora.basedragora.BaseDragora):
                 # we requested installed for caching
                 self._populateCache('installed', po_list)
                 self.infobar.set_progress(0.33)
-                self._cachingRequest('updates_all')
+                self._cachingRequest('updates')
               elif self._status == DNFDragoraStatus.CACHING_UPDATE:
                 po_list = info['result']
                 # we requested updates for caching

Basically you have to change self._cachingRequest('updates_all') to self._cachingRequest('updates') and see if the problem you noticed still persists. If you experience your expected behaviour i could try to add an option to set and let the user to get one or the other behaviour. Default is updates_all of course, but that could do what you need anyway. WDYT?

[j-mracek]

I am sorry, I don't have much time to go into details how priority works. I suggest that the best way how to investigate the issue is to look at debugsolv data (not sure, how to get them from dnfdragora). I suggest that we will see that dnfdragora did some pre-selection before the data were given to the solver. Like if you have pkgA-1.0 (priority 50), pkgA-1.0.1 (priority 55) in transaction then dnf will pick pkgA-1.0 (priority 50). But in case that pkgA-1.0.1 (priority 55) will be recognized as a best candidate for the transaction by DNFdragora, then inserted in transaction as only candidate, then dnf will install pkgA-1.0.1 (priority 55), because it was requested. For proper functionality, the solver must see pkgA-1.0 (priority 50) even if it has the same version like installed in transaction, otherwise priority rule will be not applied.

[L-U-T-i]

@anaselli, you're great - it is definitely this line. Changing as you suggest resolves the issue for me. Thank you.

An option (as you indicate) would be great, as one may prefer the way it is now. I definitely want exactly the same behavior as dnf itself provides.

About the window height - it seems to be independent of the desktop (screen) size, making dnfdragora more or less useless on smaller screens (buttons at the bottom are not visible / accessible). At least in VNC session (sorry, can not test on monitor right now...). So it may not be so small issue at the end.

By the way, would it be very complicated to make also the borders between panes movable? For me, the left pane (containing only "All" with an icon, about 10% or even less of pane width at full screen width of dnfdragora window...) is way too wide for me (unless select "Groups"), while the right one would be better if wider. And, the bottom one could most of the time be much lower...

Sorry I haven't replied earlier, I haven't time to check this thread before...

[anaselli]

@anaselli, you're great - it is definitely this line. Changing as you suggest resolves the issue for me. Thank you.

An option (as you indicate) would be great, as one may prefer the way it is now. I definitely want exactly the same behavior as dnf itself provides.

Great, i will add it since it isn't that much to work on :) And i like to have users happy ;)

About the window height - it seems to be independent of the desktop (screen) size, making dnfdragora more or less useless on smaller screens (buttons at the bottom are not visible / accessible). At least in VNC session (sorry, can not test on monitor right now...). So it may not be so small issue at the end.

I need to investigate on that, and even if i'm one if not the only one to work on libyui-gtk, that is not so easy and requires to align to libyui changes too. Please open a new issue for that i'll try to see if i can fix it maybe adding some minimum size here and there into dnfdragora.... so that we'll follow that issue there and hopefully close this one soon.

By the way, would it be very complicated to make also the borders between panes movable? For me, the left pane (containing only "All" with an icon, about 10% or even less of pane width at full screen width of dnfdragora window...) is way too wide for me (unless select "Groups"), while the right one would be better if wider. And, the bottom one could most of the time be much lower...

it is, we don't have the api to get that. It would be loved to have it, but that is not in the libyui core needs. Maybe in future i could try, and i don't hide that i thought to it already, to implement it in our libyui-mga external plugins, but i'm alone and i cannot do everything :D

Sorry I haven't replied earlier, I haven't time to check this thread before...

No problems, i think you can understand us then too ;)

[L-U-T-i]

@anaselli, thank you. I've rebuilt my package with your patch already, so for the moment I am perfectly OK. An option will be a great addition, looking forward...

I've opened another issue about dnfdragora 2.1.0 window height, as requested.

I've found a similar issue about the internal borders of dnfdragora in libyui-gtk, so it probably doesn't make sense to continue the discussion about that here? I fully understand you, and absolutely don't make any pressure, just mentioned it as a nice improvement. And, apporeciate what you've done by now, thank you again.

[anaselli]

and user configuration file

[L-U-T-i]

@anaselli, thank you for a really quick fix.

Maybe just one thing - the text you've put for this option may be misleading for some (including me at first place... ). In some (winblow$ context very often...) context, the term upgrade is related to a purchase of new (major) version, while updates (patches / fixes) are free of charge. In "free world" / more common context, upgrade is considered more or less as a major version update. In DNF, update is just a (deprecated) alias for the upgrade command (even if I personally would do it exactly opposite, as every upgrade is also an update, while it may be a subject of discussion if certain update deserves to be named also an upgrade - if it is actually just a bugfix, for instance... ;-)). So, I wouldn't understand this option meaning at all, even when consulting help (where it is explained more or less the same as the label itself is...).

As I understand the whole thing, if the option is checked, all higher versions are considered as updates / upgrades (regardless of repo priorities), and displayed in the updates list accordingly. If the option is unchecked, only new / higher versions/releases of packages (as already installed one) within the lowest priority repo are considered as updates / upgrades, and listed as such (so if there are even higher version/release packages in the other repos with higher priority, they are not listed - what is the default behavior of "dnf update" command itself).

So maybe the better label would be something as "Treat update candidates as dnf update command" or "List / consider only updates within the lowest priority weight repo" (both with checkbutton options reversed, of course - so default unchecked).

Or, label it as something like "List new / higher version/release packages from higher priority weight repos as updates", if you prefer to keep this option checked...

It is of course just my point of view... :-)

[mikhailnov]

I came here trying to understand what "Consider packages to upgrade as updates" means. Did I understand correctly that it means "Do not consider repository priorities and other dnf settings when calculating upgrades"??

[mikhailnov]

No. Wise a versa.

[anaselli]

Selecting it means dnfdragora show both upgrade and updates, as updates

[mikhailnov]

What are differences between un update and upgrade?

From dnf man:

  Upgrade Command
       Command: upgrade
       Aliases: up
       Deprecated aliases: update, upgrade-to, update-to, localupdate

       dnf [options] upgrade
              Updates each package to the latest version that is both available and resolvable.

dnf man makes no difference between updates and upgrades...

[anaselli]

Well iirc that option was added to avoid major version update and/or not from official update repos maybe, i need to check but the main difference was here:

• self._cachingRequest('updates_all')
• self._cachingRequest('updates')

and that should be related to the filter that dnf-daemon performs using "updates" or "updates_all" in get_packages query.