Bug #2178
[archlinux32] packages have higher pkgrel compared to Arch packages
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
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
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.
Updated by bill-auger about 5 years ago
ok i see - i assumed that arch32 did not preserve the arch pkgrel
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
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?
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).
Updated by bill-auger about 5 years ago
beefcake did get a big disk upgrade yesterday - the disk with repos got an extra TB
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).
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/
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?
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
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"