I am building and installing custom RPMs on Centos/RHEL 6. When deploying on containers and VMs everything works as expected, however, on the production box we have extra, internal repositories. yum install my.rpm leads to a conflict with php70w-*:
Error: php70w-common conflicts with php-common-5.3.3-46.el6_7.1.x86_64
You could try using --skip-broken to work around the problem You could
try running: rpm -Va --nofiles --nodigest
The php version chosen should be the 5.3.3 because of the RPM's requirements. php-gd is listed in the .spec which enforces that:
---> Package php-gd.x86_64 0:5.3.3-46.el6_7.1 will be installed
--> Processing Dependency: php-common(x86-64) = 5.3.3-46.el6_7.1 for package: php-gd-5.3.3-46.el6_7.1.x86_64
The interesting thing is that if I install all php-* packages by hand (exactly as listed in the .spec file) and then install the package everything works. (This verifies that the conflict has nothing to do with the rest/non-php dependencies). Note that I have AutoReqProv: no in the spec...
Questions:
I would assume that yum will choose php 5.3.3 because all dependencies are satisfied without conflicts... why isn't doing that?
How can I prevent that behavior for my.rpm installation only?
The solutions I have considered are:
Explicitly state version <=5.4 in all php requirements. However, since I don't know what makes yum pick version 7, I am not sure this will work. Also, I prefer to keep dependencies version-less if possible. Once all required php modules are available in php 7 or once our software changes and we drop php-gd, it would be nice to port to php 7 without changing all versions in specs.
In the repository definition on the host I can exclude the package. I would like to avoid this - I control the RPM spec but the repositories are set by sysadmins (using puppet)
Instruct puppet to install all php dependencies first and then deploy my.rpm. A solution I don't like because we are splitting the installation in two steps and two different systems: puppet and rpm.
Any help and/or ideas would be appreciated
php70w-common looks like a webtatic or atomic repo package.
Either way you need to determine what repo it belongs to, either to exclude selectively the repo at install time or to configure repository priorities.
You can easily find out with:
yum info php70w-common
I prefer the priorities approach, which is cleaner and more portable.
https://wiki.centos.org/PackageManagement/Yum/Priorities
Related
I am trying to install some PHP packages that I use for my application in Alpine Linux. The packages that I am currently using come from the Remi repo and I install them successfully on CentOS 7, but when I try to install tthe same packages on Alpine, it says not found. An example of a package is php-cli.
Am I doing it right or is there a recommended way of installing packages in Alpine? I am using php7 and Alpine 3.8.
Note: I am using php7- prefix when I am installing a package in Alpine.
Thanks in advance.
For locating packages for Alpine Linux, the Alpine package search engine is the best place to look for.
Querying for php7*, we can see that there are indeed no matches on the main Alpine V3.8 repository, but many matches on the community repository: php7* package search.
For installing these packages, you'll first need to add the community repository to your /etc/apk/repositories file (uncomment it, if it is commented out):
http://dl-cdn.alpinelinux.org/alpine/v3.8/community
Then, run apk update and apk add php7 [additional packages...] for installing the desired PHP 7 packages.
Specifically, php7-cli seems to be missing. For PHP 7 CLI tools, you could try installing php7-dev from the edge community repository. Similar to above, add the following to your /etc/apk/repositories, then update and install:
http://dl-cdn.alpinelinux.org/alpine/edge/community
I am trying to set up a web server to host Moodle on and I've been running into problems when trying to install PHP7.
I am currently using VirtualBox to host CentOS 7.4. By default, CentOS comes packaged with PHP 5.4.16. Now, from what I have read, the options for upgrading and installing from scratch are different. I have tried to follow multiple sites that guide towards getting PHP7 but have had no luck. The majority of guides tell you to install two repositories, Remi and EPEL. The main problem I have is that every time I install epel, yum either breaks or prevents me from installing another package.
[root#localhost ~]# yum update
Loaded plugins: fastestmirror, langpacks
Could not retrieve mirrorlist http://mirrorlist.centos.org/?
release=7&arch=x86_64&repo=os&infra=stock error was
14: curl#6 - "Could not resolve host: mirrorlist.centos.org; Unknown error"
One of the configured repositories failed (Unknown),
and yum doesn't have enough cached data to continue. At this point the only
safe thing yum can do is fail. There are a few ways to work "fix" this:
1. Contact the upstream for the repository and get them to fix the problem.
2. Reconfigure the baseurl/etc. for the repository, to point to a working
upstream. This is most often useful if you are using a newer
distribution release than is supported by the repository (and the
packages for the previous distribution release still work).
3. Run the command with the repository temporarily disabled
yum --disablerepo=<repoid> ...
4. Disable the repository permanently, so yum won't use it by default. Yum
will then just ignore the repository until you permanently enable it
again or use --enablerepo for temporary usage:
yum-config-manager --disable <repoid>
or
subscription-manager repos --disable=<repoid>
5. Configure the failing repository to be skipped, if it is unavailable.
Note that yum will try to contact the repo. when it runs most commands,
so will have to try and fail each time (and thus. yum will be be much
slower). If it is a very temporary problem though, this is often a nice
compromise:
yum-config-manager --save --setopt=<repoid>.skip_if_unavailable=true
Cannot find a valid baseurl for repo: base/7/x86_64
I have tried many ways of fixing this. Some of the main ways are:
yum clean all
yum --enablerepo=base clean metadata
rm -rf /var/cache/yum
I did get around this once or twice by using
yum --enablerepo=epel clean metadata
and also
sed -i "s/mirrorlist=https/mirrorlist=http/" /etc/yum.repos.d/epel.repo
I know there are more ways that I have tried, but I cannot remember all of them. Moral of the story is that they don't usually help. Sometimes yum works fine and I will run yum clean all, and it stops functioning again.
Method 2:
Another method I tried was installing the rpm packages from their respective websites. I used WinSCP to transfer the files to my VM and then used yum to install them. Everything works well and I got epel and remi to install. But then yum doesn't work properly.
Sometimes it will install packages, but some will not install. I've set the yum timeout value higher and other packages get through, but some still do not. Then I clean up the yum cache and once again I see the message with five options.
Method 3:
I found documentation on installing PHP 7 from https://wiki.centos.org/HowTos/php7 and I thought it must work because this is the supported way.
I followed along right up until the first part.
root # centos7-vm: ~ # yum -y install centos-release-scl.noarch
I will either get the error message stating the package could not be downloaded from a mirror or if yum is already giving me issues, it will show the five options to clean yum.
Method 4:
Building PHP from source was another option I attempted. I navigated to http://php.net/downloads.php and downloaded the tarball and used WinSCP to get it on my machine.
I extracted the files and then navigated into the php directory.
I attempted to get things going by using ./configure, but it stated I needed gcc.
I tried to install gcc with yum install gcc, but could not install all of the packages.
I made a new VM and instantly tried installing gcc, but still not luck.
Summary
Sometimes I understand why yum does not work, other times I'm slamming my head on my desk.
Is there a standardized method of getting PHP 7 on CentOS? Can anyone link an accurate guide?
What is the reason that CentOS comes packaged with PHP 5.4 and not 7?
I feel like I have tried almost everything, but I know there is some webpage that I just haven't found yet. I think I did about all the research I possibly could for today.
I'm sure my question is probably not structured the best and might be a little confusing, but I've been working on this for about 6-7 hours now.
This is my first post, so I apologize if it is not perfect.
in my vps, I just added remi repo,
$ wget http://rpms.famillecollet.com/enterprise/remi-release-7.rpm
$ rpm -Uvh remi-release-7.rpm
or
$ rpm -Uvh http://rpms.famillecollet.com/enterprise/remi-release-7.rpm
then you enable on /etc/yum.repos.d/ on remi.repo, and remi-php72.repo files.
later you update, and install php and its libraries.
epel is not necesary, but is in the official repo. you just got to do a
$ yum install epel-release
and enable the file in /etc/yum.repos.d/
have you check some logs files? to see if there's any errors
I always get this weird questions about how stuff works behind the scenes. I know how to compile php from source, and I know that if you compile it from source and forget to add a module/library you need to re-compile php to add it. However, if you install php lets say using yum, and then you want to add another extension, you just need to install that extension. For example, today I was working on a recently installed Fedora 18 machine, and php was missing the DOM library, which is weird, since that library is enabled by default. It seems like yum installs php with that extension disabled. Anyway, since it was missing, I had to do this:
sudo yum install php-xml
And that solved the problem, but it made me wonder, how is the installation process in this case? Is php re compiled? and if so, how does it remember all the other extensions that may have been added before? Or is the xml extension installed separately and somehow linked into php?
I haven't found any info about this, and I'm really curious as to how it works.
When you install php extension packages using a package manager like yum or apt-get, the repositories have the already compiled so extensions for the version of php that came with the system. For example, if you're on Ubuntu 12.04, and you do a apt-get install php-mysqlnd, it fetches the deb package from the repository which contains the pre-compiled mysqlnd.so and a default mysqlnd.ini. This works because the deb package has the compiled version according to the default dependencies that are installed for the 12.04 release. If some dependencies are missing, the precompiled deb packages are fetched for the same, thus eliminating the need for configuration and make. This make it a lot faster and easier. Almost plug and play!
You can build extensions separately, you don't have to rebuild your php every time you need to add a new extension, you just need to define the extensions that needs to be loaded under [extensions] in your php.ini.
When your building php you can specify which extensions you need to be statically (included) in the php binary vs which once you want as a shared library.
configure --enable-http=static --with-openssl=shared
// http extension will be included in PHP
// openssl extension will be compiled as separate DLL
Yum connects to repositories of pre-compiled rpm's. Yum will download the rpm and its dependencies and install them.
Yum will use different repositories for different OS's. For example Fedora 18 has a different repostitory of pre-compiled rpms then Fedora 17 would have.
Yum is just a glorified dependency management system
phpinfo() function shows that my PHP version (5.1.6) is installed --without-pear in the configure command section.
How do I install pear?
The Getting and installing the PEAR package manager page should help you : it gives informations on how to install the PEAR package manager, on both windows, Linux, and Mac.
Basically, if your Linux distribution comes with a PEAP package, you should install it.
For instance, on Ubuntu1, there is a php-pear package ; so, you'd use :
apt-get install php-pear
Else, if it doesn't, with a version of PHP >= 5.3, you should be able to use this :
$ wget http://pear.php.net/go-pear.phar
$ php go-pear.phar
With PHP 5.1, though, this is not going to work, as phar support has been added in PHP 5.3...
As a sidenote : PHP 5.1 is really outdated !
PHP 5.3 is more than one year and a half old ; even PHP 5.2 is not maintained anymore... maybe you should consider upgrading ?
1It seems you are running some kind of Redhat-based distribution, but I don't have one of those, so I cannot say if there is a PEAR package for it -- there is probably one, though.
--without-pear only means that the PEAR bits were not immediately created when PHP was compiled.
This usually happens when an operating system vendor that provides packages and wants to split off bits and pieces into their own individually installable parts.
Given the age of the PHP you're talking about, you're probably on RHEL or a derivative like CentOS. Check the package manager for a php-pear package.
I'm using yum on CentOS 5.1 - I hand-compiled PHP 5.2.8 from source, but have other packages installed using yum. I need to install a PHP extension via pecl, and it requires phpize to be installed as well. However, doing the following yields a dependency error:
sudo yum install php-devel
Error: Missing Dependency: php = 5.1.6-20.el5_2.1 is needed by package php-devel
Since I actually have a newer version of PHP already installed, how can I force yum to ignore this? Do I need to hand-compile pecl/phpize from source? I admittedly never had a problem before, it only seems to be because of a combo of compiles and yum installs.
Any thoughts?
Thanks,
Kyle
In general:
If you build it yourself, it goes into /usr/local, and is only accessible to other things in /usr/local.
If you install from RPM/Yum, it goes into /usr, and is accessible to /usr and /usr/local.
So, if you want to install PHP tools using home-compiled PHP, install them into /usr/local as well: typically, with GNU-type software, that'd be something like:
./configure --prefix=/usr/local && make && sudo make install
or
make prefix=/usr/local all && sudo make prefix=/usr/local install
…although most software should default to /usr/local unless you override its prefix setting.
If you want to “hand-build” packages that are based upon RPM's, you can use
yumdownloader --source WHATEVER-PACKAGE
rpm -i WHATEVER-PACKAGE.rpm
rpmbuild -bp ~/rpm/SPECS/WHATEVER-PACKAGE.spec
(your path equivalent to ~/rpm may vary; rpmbuild --showrc will tell you where)
This downloads the .src.rpm package, which contains the upstream (original author's) source (usually a tarball) as well as OS-specific patches; installs the sources into ~/rpm (or your rpmbuild prefix); and then unpacks the sources and applies the patches into ~/rpm/BUILD/WHATEVER-PACKAGE/
From there, you can do the configure/make steps yourself, with the /usr/local prefix
Of course, just installing from RPM's is far easier :-)
yum doesn't know anything about your hand-compiled php version. You can either bypass RPM's dependency resolution by installing the package using rpm --nodeps and hope it works.
Or install the php version you compiled yourself in another directory so it can coexist with the old version from yum, so everyone is happy (not sure if that's possible, I guess it depends on whether your apps use a hardcoded path to php or not).
Or, if you are lucky, a third-party repository like EPEL or RPMForge might have a newer php package, so you don't have to compile your own.
As a rule of thumb, it's better to have one package management in the system, so you'll be better off packaging everything in RPMS and managing it via yum. It will save you lots of time in the long run.
If you absolutely want to have something (fe PHP) compiler from sources by hand, use stow/checkinstall/... or any other solution which would enable you to do rudimentary package management for source-compiled stuff.
Regerding your question, you could try to override dependency checking by downloading RPM of the required package an doing "rpm -i --force file.rpm", since yum does not have any option for forced installations