downgrade php 7.3 on arch linux
Arch uses a severely limited pacman manager and aur. I need to run Magento, but it only runs on php 7.2. Pacman is only giving me the option for 7.3, with no php72 as it should normally have under AUR.
Why is this not included, and how do I get it installed without having to compile from source?
3 Replies
In this case you are running up agains the whole Arch ethos of prioritizing rolling releases of the newest versions of packages. Since Pacman doesn't maintain support for the the older versions you are going to need to go to the AuR and build PHP 7.2 from source.
The good news is that an AuR helper will do most of the heavy lifting for you. I strongly recommend using Yay. I followed this guide to install Yay on a brand new Arch Linode. I did find that I had to manually install some dependancies to get it to work properly. I suggest that you try the directions as listed, but for reference I will include the dependancies I had to add. For an existing system it is unlikely you will need all of them:
pacman -S make
pacman -S go
pacman -S gcc
pacman -S pkgconf
pacman -S fakeroot
pacman -S patch
pacman -S binutils
Once that is complete though, you can use Yay with all the same syntax as Pacman, so to install PHP 7.2 just run yay -S php72
And Yay will pull down and compile php 7.2 from the AuR for you.
[tbaka@localhost yay]$ php72 -v
PHP 7.2.22 (cli) (built: Sep 29 2019 23:09:57) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies
[tbaka@localhost yay]$ uname -r
5.2.2-arch1-1-ARCH
Why do we have to build yay from scratch? Yay is part of the AUR.. as is php72. I dont understand these limitations on linode. Also why was search (-s option) removed from pacman?
EDIT: Ahh Ive been using yaourt/yay for way too long.. I assumed -s was part of pacman.. my bad! Thanks for the suggestion.
It's no problem at all! And I would be happy to provide a bit more information about how we ended up here (and if any of this is old news feel free to disregard it. I'm putting it in because it might help someone else down the road).
We need to build Yay from scratch, essentially due to two things. The first is the Arch philosophy and the second is the variables in what is is already included in the installation image. Let's break this down a bit.
In many distros (Debian and its offshoots for example) you can add as many repos as you want to your src file. This lets "unofficial" or community packages be installed directly with apt. Under Arch this mindset is different. The AuR exists as a huge and valuable source of software, but Pacman does not directly interact with it. This isn't a Linode limitation, but rather its just part of how Pacman works. If you want to install something out of the AuR you are always going to have to build it from source.
Which is where Yay comes in. It is essentially just a wrapper that makes it easier to run PKGBUILD, helps manage dependancies and sourcing. A side benefit is that it uses the same syntax as Pacman, which makes it flow together nicely.
It is also good to keep in mind that unlikely many distros, Arch is by design an extremely minimal install, and our installation image only provides the basic Arch. Every installation image is different. One that has more "ease of use" which is to say preinstalled packages, will cut out some of those initial dependancies. For example, when I set up Arch on my desktop at home installing Yay was a breeze. Because the installation image I was using already contained a lot of the dependancies that I had to manually add on my Linode.
This more basic installation has the advantage of essentially eliminating bloatware, and allows much more granular control over what is running on your system. The downside is that it can increase the initial lift in getting some things running.
Finally, -s does indeed exist in Pacman. But, as you pointed out, unlike Yaourt or Yay it isn't an operation in and of itself, but rather an option you apply to -Q, take a look at the following from the man pages.
QUERY OPTIONS (APPLY TO -Q)
…
-s, --search <regexp>
Search each locally-installed package for names or descriptions that match regexp. When including
multiple search terms, only packages with descriptions matching ALL of those terms are returned. </regexp>
This means that you could run pacman -Qs *
(but don't because it will throw every package in your database onto your console) but not pacman -s php