Project

General

Profile

Bug #2178

[archlinux32] packages have higher pkgrel compared to Arch packages

Megver83 - about 5 years ago - . Updated about 5 years ago.

Status:
not-a-bug
Priority:
bug
Assignee:
% Done:

0%


Description

Arch Linux 32 packages use decimal pkgrel for their packages, which is a problem for repositories like [libre], [nonprism], [nonsystemd], and similars.

For example, gthumb:

[extra]
Arch Linux: 3.6.2-1
Arch Linux ARM: 3.6.2-1
Arch Linux 32: 3.6.2-1.0

[nonprism]
Parabola (all arch'es): 3.6.2-1.nonprism1

The problem now is that for using nonprism's gthumb you will need to run pacman -Suu, which is not the idea (the same happens with a bunch of other pkgs).

A possible solution would be that when Arch Linux 32 packages get imported, a change in pkgrel is done if its $pkgver and ${pkgrel%.*} is the same as Arch's. In that way, users will only need to run pacman -Suu in the migration step.

History

#1

Updated by bill-auger about 5 years ago

FWIW, another possible solution, if only arch32 does this, is to ask them to stop doing such a goofy thing

#2

Updated by eschwartz about 5 years ago

What's goofy about it -- archlinux32 bumps the sub-version every time they modify/rebuild the package, and parabola bumps the same sub-version for the same reason, but instead of using a simple integer, parabola uses a word plus a trailing integer.

The only issue here is that two different groups of people are trying to use the same slot for different purposes, to track different update channels. And I don't even see the issue -- if you add the nonprism repo to your pacman.conf and pacman -Syuu, you will sync the version from the newly added repo, and never get offered the archlinux32 version for any reason assuming the nonprism repo has a higher priority.

It is true that when switching from one set of repos to another, you can end up with different packages -- that is why when moving from arch testing to arch stable, the recommendation is to downgrade packages using -Syuu in order to achieve consistency with the newly configured repository list.

#3

Updated by bill-auger about 5 years ago

ok i see - i assumed that arch32 did not preserve the arch pkgrel

#4

Updated by Megver83 about 5 years ago

eschwartz wrote:

What's goofy about it -- archlinux32 bumps the sub-version every time they modify/rebuild the package, and parabola bumps the same sub-version for the same reason, but instead of using a simple integer, parabola uses a word plus a trailing integer.

The only issue here is that two different groups of people are trying to use the same slot for different purposes, to track different update channels. And I don't even see the issue -- if you add the nonprism repo to your pacman.conf and pacman -Syuu, you will sync the version from the newly added repo, and never get offered the archlinux32 version for any reason assuming the nonprism repo has a higher priority.

It is true that when switching from one set of repos to another, you can end up with different packages -- that is why when moving from arch testing to arch stable, the recommendation is to downgrade packages using -Syuu in order to achieve consistency with the newly configured repository list.

Maybe for users isn't such a big deal, although there are always ppl who don't know (newbies and Manjaro users generally) that they've to run -Suu. Plus, for devs working with other repos inside their librechroots, it's a PITA

#5

Updated by bill-auger about 5 years ago

this remind me of the -C option to librechroot

-C <FILE>     Copy this file to `$copydir/etc/pacman.conf`

i use that often to specify alternate mirrors, or to enable the arch32 [build-support] repo for example - isnt that sufficient to overcome any of these versioning quirks?

#6

Updated by Megver83 about 5 years ago

bill-auger wrote:

this remind me of the -C option to librechroot

[...]

i use that often to specify alternate mirrors, or to enable the arch32 [build-support] repo for example - isnt that sufficient to overcome any of these versioning quirks?

Hmmm, well, if I create a local repo in an external HDD with the fixed pkgrel, then it could work. However, idk how big should it be. I've a 300GB HDD with 235GB free (or we could create one in beefcake).

#7

Updated by bill-auger about 5 years ago

beefcake did get a big disk upgrade yesterday - the disk with repos got an extra TB

#8

Updated by Megver83 about 5 years ago

bill-auger wrote:

beefcake did get a big disk upgrade yesterday - the disk with repos got an extra TB

Those are good news. How can I access it? I remember that it required a LibreVPN thing, which was available through proton (R.I.P. proton :P).

#9

Updated by bill-auger about 5 years ago

Megver83 wrote:

How can I access it?

winston is setup as the proxy exactly the same way as it was on proton - if you had it working before, just change 'proton' to 'winston'

there is (i think) about 5GB under /home/ and about 30GB for librechroots under /var/lib/ - if you need to use the big disk, create a new dir under /mnt/data/

#10

Updated by Megver83 about 5 years ago

bill-auger wrote:

Megver83 wrote:

How can I access it?

winston is setup as the proxy exactly the same way as it was on proton - if you had it working before, just change 'proton' to 'winston'

there is (i think) about 5GB under /home/ and about 30GB for librechroots under /var/lib/ - if you need to use the big disk, create a new dir under /mnt/data/

what about /opt?

#11

Updated by bill-auger about 5 years ago

/opt is on the / disk - there is only 5GB free - i would use only a small part of that if it is essential; but leave most of that space for the system

#12

Updated by lukeshu about 5 years ago

  • Status changed from info needed to not-a-bug

Just set the [nonprism] pkgrel to arch32 pkgrel+".nonprismX"

Also available in: Atom PDF