[Resolved - Not possible currently] Equal priority repositories?

amish · 2026-03-23 08:04:58

Situation:
Many of my systems use package perl-par-packer which currently depends on exact version of perl (currently depends on perl=5.42.0)

Recently perl was updated to 5.42.1.

Ideally this perl update should have rebuilt perl-par-packer too. (by bumping pkgrel from 1.064-2 to 1.064-3 and changing depends on 5.42.1)

But it often does not get updated automatically and then pacman fails to update all my systems due to one single package dependency failing.

> :: unable to satisfy dependency 'perl=5.42.0' required by perl-par-packer

Solution:
I can manually rebuild perl-par-packer (to say new pkgrel 1.064-3 which depends on perl=5.42.1) and put it in my custom repo.

$ cat /etc/pacman.conf
...
[custom]
Server = https://foo.com/$repo

[core]
Include = /etc/pacman.d/mirrorlist

Here custom repo gets priority over core repo and then it will install my custom perl-par-packer (1.064-3).

My problem is that when, in future, core repository updates to new version of perl-par-packer to say, version 1.065-1, then my systems will not update to it because version 1.064-3 of my custom repository gets higher priority. And they all will forever remain on that version till I remove the package from my custom repository.

I think there should be option in pacman.conf to mention repository priority.

For example:

$ cat /etc/pacman.conf
...
[custom]
Server = https://foo.com/$repo
Priority = 10

[core]
Include = /etc/pacman.d/mirrorlist
Priority = 10

In such cases perl-par-packer having highest version from any of above repositories will be installed. And transition would be seemless without manual intervention.

Is there any other way to achieve this? Then please do let me know.

Thank you.

Last edited by amish (2026-03-23 16:29:18)

Allan · 2026-03-23 08:15:56

Put your repo below. Pacman will warn you have a newer version and continue its business. Or don't put it in a repo at all.

Also, use "1.064-2.1" as your version, and any update in core will fix it.

I'm also very surprised that perl-par-packer did not update with perl.... Ah - packager appears to want to avoid any checks for needed rebuilds:

  if [[ "$BUILDTOOL" == devtools ]]; then
    local perl_dep="perl=$(perl -e 'print substr($^V, 1)')"
    # this is added to the PKGINFO data
    depends+=($perl_dep)
  else
    # this is adde to the SRCINFO data
    depends+=(perl)
  fi

Seems like a dumb idea to solve another problem.

amish · 2026-03-23 09:01:13

Allan wrote:

Put your repo below. Pacman will warn you have a newer version and continue its business. Or don't put it in a repo at all.

In that case, my systems will not update to the version that I rebuilt as it would be in lower priority repository. And pacman will still fail with the dependency issue.

Allan wrote:

Also, use "1.064-2.1" as your version, and any update in core will fix it.

Aha! I did not know that you can have decimal in pkgrel too.

But that would still not solve my problem.

I am trying to avoid manual intervention in all systems.

My intention is that in such a situation. I update perl-par-packer package in my custom repository. And then future updates in core repository will automatically happen, even if I do not remove the package from my custom repository. Hence the need for a new feature of equal priority repositories.

Allan wrote:

I'm also very surprised that perl-par-packer did not update with perl.... Ah - packager appears to want to avoid any checks for needed rebuilds:
  if [[ "$BUILDTOOL" == devtools ]]; then
    local perl_dep="perl=$(perl -e 'print substr($^V, 1)')"
    # this is added to the PKGINFO data
    depends+=($perl_dep)
  else
    # this is adde to the SRCINFO data
    depends+=(perl)
  fi
Seems like a dumb idea to solve another problem.

Yes I noticed that too, but I have no clue why packager did that.

Allan · 2026-03-23 09:03:56

Ah - you want to update a single repo for multiple machines. I can not think of a way to do that.

But I bet waiting a day will be a genuine solution!

amish · 2026-03-23 09:24:01

Allan wrote:

But I bet waiting a day will be a genuine solution!

Umm, waiting from few days for perl-par-packer to get updated. But has not happened.

I created this thread because this would happen almost everytime and I have to manually rebuild perl-par-packer package everytime perl updates. And upload to my custom repo.

And then again keep tracking everyday to manually remove perl-par-packer from my custom repo when perl-par-packer is updated in extra repo.

Anyway lets see.

seth · 2026-03-23 15:43:51

When you predict to run into this, add the custom build w/ decimal increment to the local repo, update the systems, remove the package from the local repo (which is now effectively empty) and rely on pacman to not downgrade the package (also breaking dependencies) until the extra repo gets the new package?

Also you should probably file a packaging bug - this is not a simple "package is out of date" situation, the package is spell-bound to the pacman version, so (assuming that's a hard requirement tbw) they have to update atomically.

amish · 2026-03-23 15:50:07

I cant update systems and remove package. As I cant update all systems at same time. Some systems may take few days to update based on approval for downtime.

Also I had already filed bug report earlier today:
https://gitlab.archlinux.org/archlinux/ … rk_items/1

Last edited by amish (2026-03-23 15:51:17)

seth · 2026-03-23 16:09:35

cant update all systems at same time. Some systems may take few days

So the update process takes some days but that doesn't change anything about the principle approach?

amish · 2026-03-23 16:27:59

What principle approach are you talking about?

To delete the package from custom repo once all systems are updated?

That again makes things manual. I have to keep remembering one additional task till all systems are updated. If I forget one system then things will break on that system.

Anyway - I guess unless pacman has feature of equal priority repositories - this will remain manual process for me to certain extent.

So we can close this topic.

Lone_Wolf · 2026-03-29 10:29:12

Moderator Note

Closing as requested

Arch Linux

#1 2026-03-23 08:04:58

[Resolved - Not possible currently] Equal priority repositories?

#2 2026-03-23 08:15:56

Re: [Resolved - Not possible currently] Equal priority repositories?

#3 2026-03-23 09:01:13

Re: [Resolved - Not possible currently] Equal priority repositories?

#4 2026-03-23 09:03:56

Re: [Resolved - Not possible currently] Equal priority repositories?

#5 2026-03-23 09:24:01

Re: [Resolved - Not possible currently] Equal priority repositories?

#6 2026-03-23 15:43:51

Re: [Resolved - Not possible currently] Equal priority repositories?

#7 2026-03-23 15:50:07

Re: [Resolved - Not possible currently] Equal priority repositories?

#8 2026-03-23 16:09:35

Re: [Resolved - Not possible currently] Equal priority repositories?

#9 2026-03-23 16:27:59

Re: [Resolved - Not possible currently] Equal priority repositories?

#10 2026-03-29 10:29:12

Re: [Resolved - Not possible currently] Equal priority repositories?

Board footer