You are not logged in.
Pages: 1
I have added this custom x64-v3 port to pacman list and repos.
#Add the appropriate repos above your regular Archlinux repos.
#Example for x86-64-v3:
[core-x86-64-v3]
Include = /etc/pacman.d/alhp-mirrorlist
[extra-x86-64-v3]
Include = /etc/pacman.d/alhp-mirrorlist
[community-x86-64-v3]
Include = /etc/pacman.d/alhp-mirrorlist
[core]
Include = /etc/pacman.d/mirrorlist
[extra]
Include = /etc/pacman.d/mirrorlist
[community]
Include = /etc/pacman.d/mirrorlist
right now there are an update for pacman-contrib
pikaur pacman-contrib
Searching... [#=> GET https://aur.archlinux.org/rpc/?v=5&type=search&arg=pacman-contrib&by=name-desc
##
1) community-x86-64-v3/pacman-contrib 1.5.2-1.1 [installed]
Contributed scripts and tools for pacman systems
2) community/pacman-contrib 1.5.3-1 [installed: 1.5.2-1.1]
but it is only in the v1-official repo
and in the v3 port it is still older version ( usually v3 has a delay because it is not an official repo and had to build packages after every official package update)
usually if a package is newer in v1 repo it overrides the version in v3 custom repo and gets updated to that.
but it seems with this package the new version from official repo is not updated.
and if I install the new one from v1 port and then do a -Syu update it complain about local package being newer than the Database one
warning: pacman-contrib: local (1.5.3-1) is newer than community-x86-64-v3 (1.5.2-1.1)
even though I just install it from pacman command with :
pacman -S community/pacman-contrib
why in this instance this happens?
Offline
Iirc, pacman prioritizes mirrors top-down and only considers the package from the first mirror that contains it for updates.
Hence, if a priority mirror, i.e. one at the top, has an outdated package and a mirror below has a newer version, it will not be updated.
Edit: :s/mirror/repo/g
Last edited by schard (2022-06-11 17:50:35)
Inofficial first vice president of the Rust Evangelism Strike Force
Online
Iirc, pacman prioritizes mirrors top-down and only considers the package from the first mirror that contains it for updates.
Hence, if a priority mirror, i.e. one at the top, has an outdated package and a mirror below has a newer version, it will not be updated.
if that is so then why before this it would use the v1 repos that are at the bottom for other updates over v3 that are on top.
I explicitly remember packages that got new version just like this pacman-contrib but those would get updated from v1.
and I think I said so as much in my first post.
Offline
usually if a package is newer in v1 repo it overrides the version in v3 custom repo and gets updated to that.
here.
Offline
The order of repositories in the configuration files matters; repositories listed first will take precedence over those listed later in the file when packages in two repositories have identical names, regardless of version number
https://archlinux.org/pacman/pacman.con … y_sections
if that is so then why before this it would use the v1 repos that are at the bottom for other updates over v3 that are on top.
Your other repo might not have contained that specific package then
Inofficial first vice president of the Rust Evangelism Strike Force
Online
man pacman.conf wrote:The order of repositories in the configuration files matters; repositories listed first will take precedence over those listed later in the file when packages in two repositories have identical names, regardless of version number
https://archlinux.org/pacman/pacman.con … y_sections
rezad wrote:if that is so then why before this it would use the v1 repos that are at the bottom for other updates over v3 that are on top.
Your other repo might not have contained that specific package then
as I said ,before this it overrided it.
as in there are two version after update check:
community-x86-64-v3/specific-package #lowerversion
community-/specific-package #higherversion
this usually for me would cause the second one to be updated to.
but with this new package I saw what you described.
again: I understood even before the my post that pacman give higher priority to upper repos.
but for me and my update it was as if it would first check upper ones and then if it was newer in lower ones (v1) then would the lower repo but higher version number.
I remember that because I would see that package would get switched from community-x86-64-v3 to community because the second one had a newer version even though the v3 is higher priority.
and I dont remember lowering or upping the places of my repos in pacman conf because from the start when I added that new repo in its guide it said to put it at top to get higher priority.
Offline
usually if a package is newer in v1 repo it overrides the version in v3 custom repo and gets updated to that.
Not if it's located below the v3 repo in your pacman.conf (which is the case in your pacman.conf).
If you observed that previously, that might have been because either the affected packages were not in the v3 repo yet, or perhaps your repos were arranged differently then, or maybe it's just some pikaur-specific quirk that we can't help much with.
and if I install the new one from v1 port and then do a -Syu update it complain about local package being newer than the Database one
warning: pacman-contrib: local (1.5.3-1) is newer than community-x86-64-v3 (1.5.2-1.1)
That is expected. It compares with the first package it finds (which is in the v3 repos, and it's older).
even though I just install it from pacman command with :
pacman -S community/pacman-contrib
Pacman doesn't track which repository a package came from (so it doesn't "remember" that a package came from v1), so for an update, it simply compares a local pacman-contrib with the first one it finds in a repo, which happens to be in v3.
--edit Wow, I missed a big part of the conversation from afterwards.
Right now the behaviour of pacman that you show us matches what is expected (and what's documented), so…
You would need to show us a specific counter-example (not just paraphrasing) of when it behaves/behaved differently. Maybe an excerpt from pacman.log?
Last edited by ayekat (2022-06-10 17:52:30)
Offline
[2022-05-11T21:28:01+0430] [ALPM] upgraded containerd (1.6.3-1.1 -> 1.6.4-1)
[ALPM] upgraded llvm-libs (13.0.1-3.1 -> 13.0.1-4)
the -1.1 is for the v3 ports and the -1 is for the v1 port.
as I said from the start I put the repo at the top of pacman config because I know about priorities and more importantly the guide for adding this repo said to do that.
Last edited by rezad (2022-06-11 14:52:14)
Offline
how does pacman compare a package from two repos with higher and lower priorities?
I understand this
H repo:x-y.1
L repo:x-y)
causing update to H repo package
what about these:
for example if higher repo version is:1.6.3-1.1 and the lower one is 1.6.4-1 like my log says.
higher repo version is:1.6.3-1.1 and the lower one is 1.6.4-2.2.
how about higher one 1.6.4-1 and lower one being 1.6.3-4.4
how about
[ALPM] upgraded llvm-libs (13.0.1-3.1 -> 13.0.1-4)
Last edited by rezad (2022-06-11 14:51:27)
Offline
It doesn't. The first one it finds wins.
Offline
It doesn't. The first one it finds wins.
I have no idea what you mean.
there is no first one.
two repos get updated.
you are saying if first repo has a firefox version 78-1 and the second one has firefox version 20000-2000.222 then firefox wont get updated?
Offline
Who cares what repo was updated.
I hadn't read the whole thread, turns out this was already explained multiple times and you just refuse to accept the answer. Nevermind, I'm not doing this.
Offline
Iirc, pacman prioritizes mirrors top-down and only considers the package from the first mirror that contains it for updates.
Hence, if a priority mirror, i.e. one at the top, has an outdated package and a mirror below has a newer version, it will not be updated.Edit: :s/mirror/repo/g
then why this happended for me?
[2022-05-11T21:28:01+0430] [ALPM] upgraded containerd (1.6.3-1.1 -> 1.6.4-1)
the 1.1 is the higher repo but the lower repo is newer.
Offline
Given you have posted one line from your log, there could be many reasons...
1) the old containerd was not still in the x86_64_v3 repo when you updated
2) you manually installed the newer version from the arch repos
3) another package pulled the newer version as a dependency. (I'd bet on this...)
4) ...
Offline
Given you have posted one line from your log, there could be many reasons...
1) the old containerd was not still in the x86_64_v3 repo when you updated
2) you manually installed the newer version from the arch repos
3) another package pulled the newer version as a dependency. (I'd bet on this...)
4) ...
1) the old one compared as shown in log so it is there.
2) I didnt.
3) that may be the case if pacman can specify version for dependency. can it?
Offline
1) the old one compared as shown in log so it is there.
2) I didnt.
3) that may be the case if pacman can specify version for dependency. can it?
1) that does not mean it was not removed since you installed it.
2) we can not tell because you have not provided the relevant log entries...
3) yes.
Offline
I think I wait until I get new instances of this issue then report back.
Offline
Pages: 1