Skip to main content ↑ ↓
Topic: Using x86_64-v3 repositories (Read 5037 times) previous topic - next topic
0 Members and 5 Guests are viewing this topic.

Using x86_64-v3 repositories

For about 5 to 20% more performance/efficiency in systems newer than ~8 years old, especially for those affected by recent mitigations, you can use these v3 repositories.
This guide is by all means unofficial and incomplete, but enough packages can be replaced to make a difference.

What do they contain:
- CachyOS - Optimized kernel called linux-cachyos, and builds of some programs like LibreWolf, Wine, FileZilla etc.
- ALHP - An almost complete replacement of Arch's extra. Has libsystemd components so it requires artix-archlinux-support.

To ease the process I won't bother you with mirrorlists since I don't use them either, so just 2 servers per each will probably suffice, with the cdn mirror first to ensure reliability.

Installation:

1. If you want to use ALHP add their key (or install alhp-keyring from AUR):
Code: [Select]
# pacman-key --recv-keys E3D0D2CD3952E298 --keyserver keyserver.ubuntu.com; pacman-key --lsign-key E3D0D2CD3952E298
2. If you want to use CachyOS add their key...
Code: [Select]
# pacman-key --recv-keys F3B607488DB35A47 --keyserver keyserver.ubuntu.com; pacman-key --lsign-key F3B607488DB35A47
...and add this to the Architecture line in /etc/pacman.conf:
Quote
Architecture = x86_64 x86_64_v3
3. Add their repositories:
Code: [Select]
#
# REPOSITORIES
#

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

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

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

[cachyos-v3]
Server = https://mirror.cachyos.org/repo/$arch_v3/$repo
Server = https://aur.cachyos.org/repo/$arch_v3/$repo

[extra-x86-64-v3]
Server = https://alhp.krautflare.de/$repo/os/$arch
Server = https://alhp.dev/$repo/os/$arch

[extra]
Include = /etc/pacman.d/mirrorlist-arch

*Info: For safety's sake they are place below Galaxy in this example. You can try to add them above at your own risk, for more replaced packages at the cost of maybe a few small conflicts down the line.
If you're more adventurous, cachyos-v3 can be added even further towards the top (as it's a smaller repo without libsystemd stuff), it replaces some more potentially useful pkgs. depending on your usage.

Upgrade, reboot and that's it. Stability has been fine for me, for the past year or so already, so I can recommend this. :-)

Re: Using x86_64-v3 repositories

Reply #1 –
I have updated the guide for the recent repo changes since last month and tested a while. If you want to try this it will be most likely trouble free, especially with the custom kernel if you don't want to touch anything else.

Re: Using x86_64-v3 repositories

Reply #2 –
Just tried this out and its working well so far on kde/runit, thanks for this guide.
Using cachy kernel and their binaries for mesa, radv, wine, and a few others.

Re: Using x86_64-v3 repositories

Reply #3 –
Quote from: Hitman – on
For about 5 to 20% more performance/efficiency ... Stability has been fine for me, for the past year or so already, so I can recommend this. :-)

Thank you so much! I won't use any extra repos but my "architecture" option in "/etc/pacman.conf" was set to "auto" and I read the manual, and it says that when it's set to that, it will get the value given by the "uname -m" option and for me, that was "x86_64" so, I wasn't getting the "v3" options!

One question! Why setting both "x86_64" and "x86_64_v3" and not just the latter?
 

Re: Using x86_64-v3 repositories

Reply #4 –
I have Architecture = auto and I do get the v3 packages from ALHP.

The reason you might need both is there are not v3 versions of all packages provided by ALHP. I assume CachyOS is similar?
You can see the package statuses at https://status.alhp.dev/
Their github also has more info https://github.com/an0nfunc/ALHP

Re: Using x86_64-v3 repositories

Reply #5 –
Quote from: gripped – on
I have Architecture = auto and I do get the v3 packages from ALHP.

The reason you might need both is there are not v3 versions of all packages provided by ALHP. I assume CachyOS is similar?
You can see the package statuses at https://status.alhp.dev/
Their github also has more info https://github.com/an0nfunc/ALHP


Thank you for the reply! I will try CachyOS repos!

Re: Using x86_64-v3 repositories

Reply #6 –
If i'm not wrong the reason CachyOS repos need a separate arch. entry is because they chose to follow the standard to specify the compile flags directly in the root directory of their host, which for convenience sake ALHP has skipped (thus their arch. line stays the same, variants v2/3/4 are named in the repo title instead).
Leaving just x86_64_v3 means of course the normal repos don't get fetched, although it won't probably be that hard to mirror the artix gitea and make an own build server with these flags. (I want to but lack time and server gear)

Re: Using x86_64-v3 repositories

Reply #7 –
Quote from: Hitman – on
If i'm not wrong the reason CachyOS repos need a separate arch. entry is because they chose to follow the standard to specify the compile flags directly in the root directory of their host, which for convenience sake ALHP has skipped (thus their arch. line stays the same, variants v2/3/4 are named in the repo title instead).
Leaving just x86_64_v3 means of course the normal repos don't get fetched, although it won't probably be that hard to mirror the artix gitea and make an own build server with these flags. (I want to but lack time and server gear)

Thank you so much! All that was very helpful!

Re: Using x86_64-v3 repositories

Reply #8 –
If both ALHP and CachyOS provide the same packages, which one should I choose for optimal usage? I wonder if there could be some external patches and fine-tuning that I can’t find information on.

Re: Using x86_64-v3 repositories

Reply #9 –
Quote from: Shoun2137 – on
If both ALHP and CachyOS provide the same packages, which one should I choose for optimal usage? I wonder if there could be some external patches and fine-tuning that I can’t find information on.
I use ALHP but not CachyOS.
Both just use custom flags when compiling vanilla Arch PKGBUILDS's but CachyOS also has a custom patched kernel.
Maybe CachyOS has other customized PKGBUILD's ? Not totally sure. To the best of my knowledge ALHP is all vanilla PKGBUILD's

More information
https://github.com/CachyOS/linux-cachyos
https://github.com/an0nfunc/ALHP

Re: Using x86_64-v3 repositories

Reply #10 –
eh
I thought I’d try Cachy Browser since it’s based on Librewolf+x86-64-v3 but they’ve disabled unsigned addon usage and there's no way to reenable it, which is stupid as hell since I can’t use my own inhouse addons that I created, hell no, no way am I giving those to mozilla. Quite sad.

Re: Using x86_64-v3 repositories

Reply #11 –
I noticed that there's a huge problem while updating the packages when you use x86-64-v3 repos that I'm not sure how to solve...

So, let's set up a scenerio:
- Arch support enabled
- x86_64_v3 ALHP/CachyOS repos enabled
- Repo order:
Code: [Select]
[system]
[world]
[galaxy]
[cachyos-v3]
[extra-x86-64-v3]
[lib32]
[extra]
[multilib]

Let's take mpv for example, it's available in:
world/mpv
extra-x86-64-v3/mpv
extra/mpv

I explicitly installed extra-x86-64-v3/mpv at version 1:0.38.0-5.2 at some point, some time passes, I want to update my Artix.
I was kinda bummed when some of packages were pulled from vanilla repos even tho I installed the x86-64-v3, but it makes perfect sense, it's setup as it is above, and pacman simply adheres to it.

What should I do to update all my stock packages + update explicitly installed packages from the exact repo they are?

Because pacman -Syu will pull mpv 1:0.38.0-6 just as it should from world, not from extra-x86-64-v3 even when mpv 1:0.38.0-6.1 is available. Now well, imagine that we setup several packages to be x86-64-v3, it'd replace all of those HP packages, because of the top-down priority, but the thing is, we're running Artix, it needs to be setup as it is in the OP post.

I tried searching for a solution, but scavenging for info on this somewhat hard due to people just simply gaslighting people into saying shit is unsupported/"you shouldn't do that" ;/
Any ideas?

Re: Using x86_64-v3 repositories

Reply #12 –
@Shoun2137
I don't think you can achieve this automatically simply.
But there's things you can do to help with varying degrees of automation.

If you uncomment VerbosePkgLists in /etc/pacman.conf you get to see which repos packages are being pulled from on updates.

If you add the packages you want to come from extra-x86-64-v3 to IgnorePkg you'll get a warning when a upgrade is available and can then explicately install them from the repo you want.

You can create a pacman (libalpm) hook that triggers whenever packages you specify get updated and tells you to reinstall them from extra-x86-64-v3.
You can't unfortunately make the hook reinstall the packages automatically as until the pacman process exits its lockfile prevents it running again. (there is a convoluted way of getting round this but I've never managed to get this to work with sudo, only a root shell)

You can create a cron job (or possibly another hook) to run a script to manage a local repo containing only the packages you want from extra-x86-64-v3 and put it at the top of the list.
I have no idea with CachyOS but for ALHP there's an API you can query for info about packges
This python function returns a dict of all the -v3 pkgbase's
Spoiler (click to show/hide)
It would be nice if there was a simpler way, but to the best of my knowledge there isn't.

Re: Using x86_64-v3 repositories

Reply #13 –
I've poked around for solutions, but those either turned to be very slow when trying to poll/organise packages, because you have to rummage through all of them to make sure those are actually v3/v4 manually so it's a shame this particular pacman dev doesn't care about actually basic stuff that should be on Arch from day one. With this feature, it'd be trivial to identify by just reading local pacman db file directly. As for CachyOS fork of pacman, yes, it'd be way easier due the patch above, but you have to install it before any v3/v4 package, so that it actually keeps track of what you install. If you do it after that, well, the damage is done, you don't have that info embedded in local db. Also you still need to write a wrapper of some sort that will update v3/v4 packages first, and then do normal update (and then aur at last) ;/

I didn't even try to poll by ALHP API because the effort required would outweigh all the pros for so little benefit, it'd also mean that you need internet connection just to verify what you actually run on your device... pointless and useless.

So sadly I can't recommend running v3/v4 packages on Artix simply due to the fact that it's really hard to track packages, if you plan to replace significant part of the system + most of the packages are linked against systemd so breakage is unavoidable. The performance difference doesn't make up for the effort. Thank you for the tutorial.

Re: Using x86_64-v3 repositories

Reply #14 –
Quote from: Shoun2137 – on
So sadly I can't recommend running v3/v4 packages on Artix simply due to the fact that it's really hard to track packages
It's really not hard to check if a package in the local database is from Artix, Arch or ALHP.
As the discussion around the merge request you linked stated it's trivial to discover the organisation behind an installed package using the 'packager' field.

Quote
I didn't even try to poll by ALHP API because the effort required would outweigh all the pros for so little benefit, it'd also mean that you need internet connection just to verify what you actually run on your device... pointless and useless.
The point of accessing the ALHP API would be to check for updates to ALHP packages already installed locally and then download them and add them to the local repo. Which is going to require an internet connection anyway. To check the packager in the local database does not require an internet connection.
 
Quote
if you plan to replace significant part of the system + most of the packages are linked against systemd so breakage is unavoidable.
To the contrary most are not linked against systemd.

I enjoy playing around with this stuff.
This shows where my installed packages come from:
Spoiler (click to show/hide)
Quote
I've poked around for solutions
Sometimes you have to make your own.
I have various scripts to help me.
But in the main I won't be sharing them on here as it's likely people will break their systems and then blame me no matter how many warnings I include.
Plus I worry that some of what I do personally could be seen as disrespectful to the Artix devs if I try and promote it. So I don't.