Howdy,
My name is Carl, and I'm a developer for the IUS Community repository.
CentOS users have easy access to the EPEL repo because the epel-release RPM is in the CentOS Extras repository. Obviously CentOS and EPEL have a special relationship, since they are both sponsored by Red Hat. A coworker suggested to me that it would be nice if the ius-release RPM could be included in Extras as well. I brought the idea up in IRC, and Karanbir suggested I draft up a specification that any third party repository can follow to be considered for inclusion. Here is what I have so far.
https://gist.github.com/cgtx/b854281462a18007f509
If this looks familiar, it's because I used the IUS SafeRepo Initiative as a starting point. Please share your feedback and ideas.
Carl George Rackspace RPM Development
On Sat, Mar 28, 2015 at 3:32 PM, Carl George carl.george@rackspace.com wrote:
Howdy,
My name is Carl, and I'm a developer for the IUS Community repository.
CentOS users have easy access to the EPEL repo because the epel-release RPM is in the CentOS Extras repository. Obviously CentOS and EPEL have a special relationship, since they are both sponsored by Red Hat. A coworker suggested to me that it would be nice if the ius-release RPM could be included in Extras as well. I brought the idea up in IRC, and Karanbir suggested I draft up a specification that any third party repository can follow to be considered for inclusion. Here is what I have so far.
https://gist.github.com/cgtx/b854281462a18007f509
If this looks familiar, it's because I used the IUS SafeRepo Initiative as a starting point. Please share your feedback and ideas.
Besides categorizing 3rd party repos into ones with/without policies to not overwrite base packages, is there any chance of setting up a central service that would do the equivalent of 'yum search' and 'yum info' on a system with all of them enabled and show the results?
On Sat, Mar 28, 2015 at 4:32 PM, Carl George carl.george@rackspace.com wrote:
Howdy,
My name is Carl, and I'm a developer for the IUS Community repository.
CentOS users have easy access to the EPEL repo because the epel-release RPM is in the CentOS Extras repository. Obviously CentOS and EPEL have a special relationship, since they are both sponsored by Red Hat. A coworker suggested to me that it would be nice if the ius-release RPM could be included in Extras as well. I brought the idea up in IRC, and Karanbir suggested I draft up a specification that any third party repository can follow to be considered for inclusion. Here is what I have so far.
https://gist.github.com/cgtx/b854281462a18007f509
If this looks familiar, it's because I used the IUS SafeRepo Initiative as a starting point. Please share your feedback and ideas.
Carl George Rackspace RPM Development
Scientific Linux does this effectively. Unfortunately, if your reason to exist is "to be a byte for byte matching duplicate of RHEL", it gets awkward. And many of the 3rd party repositories can, and do conflict with the base RHEL packages and the base EPEL packages. And the difficulty of keeping things consistent does not go up in a linear fashion, it's more exponential or combinatorial.
One classic such difficulty is the RPMforge/EPEL disagrrements about how to package and version nagios-plugins: the "nagios-plugins" from EPEL has only a few plugins, and the other plugins are in distinct packages. RPMforge chose to have most of the plugins in the basic "nagios-plugins" package itself, since they're all deployed form the same source package. So when the EPEL had a more recent verison of 'nagios-plugins', it would replace the RPMforge version and yank out all the subpackages, unless you added them back explicitly. And if RPMforge became more recent, it would try to update and break on all the packages form EPEL.
"mysql-libs" is even worse, since no two 3rd party repos for MySQL can agree on a naming scheme for MySQL packages, and many of them mark "Obsoletes: mysql-libs" so that they can install gracefully against only the RHEL based stack.
Perl module dependency resolution is also a !@#$, because of the dependencies on older and newer builds among alternative compnent trees. I ran into this headlong woth RT and Bugzilla some time back.
On 03/29/2015 09:32 AM, Carl George wrote:
https://gist.github.com/cgtx/b854281462a18007f509
If this looks familiar, it's because I used the IUS SafeRepo Initiative as a starting point. Please share your feedback and ideas.
Sure:
Must not have the same name as a stock distribution package.
Must not automatically install, upgrade, or replace stock distribution packages when the repository is enabled.
How do the above two rules affect a repository that is not enabled by default but would end up replacing stock packages if it is enabled by the user? As an example, this would happen with CentOS's own centosplus repository which is included in the centos-release package.
What about a 3rd-party group that distributes a .repo file with one repo that is enabled by default which is intended (by policy) to not replace stock packages, and another that comes disabled with explicit instructions on how to enable it and use it (more or less) safely, the latter being intended to replace stock packages?
Peter
On Sat, Mar 28, 2015 at 11:40 PM, Peter peter@pajamian.dhs.org wrote:
On 03/29/2015 09:32 AM, Carl George wrote:
https://gist.github.com/cgtx/b854281462a18007f509
If this looks familiar, it's because I used the IUS SafeRepo Initiative as a starting point. Please share your feedback and ideas.
Sure:
Must not have the same name as a stock distribution package.
Must not automatically install, upgrade, or replace stock distribution packages when the repository is enabled.
How do the above two rules affect a repository that is not enabled by default but would end up replacing stock packages if it is enabled by the user? As an example, this would happen with CentOS's own centosplus repository which is included in the centos-release package.
And Percona, and the mysql community repository, and RPMforge. RPMforge, I'm afraid, has become particularly perilous as it's become less maintained and components are now out of date (such as the Subversion packages I used to publish there.)
Don't get me going on JPackage, which seems to be quite idle now.
What about a 3rd-party group that distributes a .repo file with one repo that is enabled by default which is intended (by policy) to not replace stock packages, and another that comes disabled with explicit
Works for me!
instructions on how to enable it and use it (more or less) safely, the latter being intended to replace stock packages?
Especially if the packages can be roughly segregated: the maven suite, for instance, is quite large and interwoven with other Java based utilities and needs to be managed cautiously, or jpackage, which hasn't been noticeably udpated since.... Fedora 17.
Thanks everyone for the feedback so far.
Considering centosplus and other repos that replace packages directly (same name), I can modify the proposal to accommodate. The biggest issues with this style of repo is that users typically blindly enable them, despite guidelines to the contrary from the repo maintainer. I can change the proposal to state that this style of repo is allowed, but must be disabled, with comments about why it is disabled. This may help prevent some users from blindly enabling it without understanding the consequences.
How does this phrasing work for yall?
* If the repository has the potential to replace stock packages when `yum update` is run, it must be disabled by default. * If the repository is disabled by default, comments must be included in the repo file to explain why.
Carl George Rackspace RPM Development
________________________________________ From: centos-devel-bounces@centos.org centos-devel-bounces@centos.org on behalf of Peter peter@pajamian.dhs.org Sent: Saturday, March 28, 2015 10:40 PM To: centos-devel@centos.org Subject: Re: [CentOS-devel] including 3rd party repo release RPMs in Extras
On 03/29/2015 09:32 AM, Carl George wrote:
https://gist.github.com/cgtx/b854281462a18007f509
If this looks familiar, it's because I used the IUS SafeRepo Initiative as a starting point. Please share your feedback and ideas.
Sure:
Must not have the same name as a stock distribution package.
Must not automatically install, upgrade, or replace stock distribution packages when the repository is enabled.
How do the above two rules affect a repository that is not enabled by default but would end up replacing stock packages if it is enabled by the user? As an example, this would happen with CentOS's own centosplus repository which is included in the centos-release package.
What about a 3rd-party group that distributes a .repo file with one repo that is enabled by default which is intended (by policy) to not replace stock packages, and another that comes disabled with explicit instructions on how to enable it and use it (more or less) safely, the latter being intended to replace stock packages?
Peter _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
Carl George Rackspace RPM Development
________________________________________ From: centos-devel-bounces@centos.org centos-devel-bounces@centos.org on behalf of Peter peter@pajamian.dhs.org Sent: Saturday, March 28, 2015 10:40 PM To: centos-devel@centos.org Subject: Re: [CentOS-devel] including 3rd party repo release RPMs in Extras
On 03/29/2015 09:32 AM, Carl George wrote:
https://gist.github.com/cgtx/b854281462a18007f509
If this looks familiar, it's because I used the IUS SafeRepo Initiative as a starting point. Please share your feedback and ideas.
Sure:
Must not have the same name as a stock distribution package.
Must not automatically install, upgrade, or replace stock distribution packages when the repository is enabled.
How do the above two rules affect a repository that is not enabled by default but would end up replacing stock packages if it is enabled by the user? As an example, this would happen with CentOS's own centosplus repository which is included in the centos-release package.
What about a 3rd-party group that distributes a .repo file with one repo that is enabled by default which is intended (by policy) to not replace stock packages, and another that comes disabled with explicit instructions on how to enable it and use it (more or less) safely, the latter being intended to replace stock packages?
Peter _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On 03/31/2015 07:37 AM, Carl George wrote:
How does this phrasing work for yall?
- If the repository has the potential to replace stock packages when
`yum update` is run, it must be disabled by default.
- If the repository is disabled by default, comments must be included
in the repo file to explain why.
That works for me :-)
Peter
On 03/30/2015 10:29 PM, Peter wrote:
On 03/31/2015 07:37 AM, Carl George wrote:
How does this phrasing work for yall?
- If the repository has the potential to replace stock packages when
`yum update` is run, it must be disabled by default.
- If the repository is disabled by default, comments must be included
in the repo file to explain why.
That works for me :-)
+1 from me
On Mon, Mar 30, 2015 at 3:44 PM, Manuel Wolfshant wolfy@nobugconsulting.ro wrote:
On 03/30/2015 10:29 PM, Peter wrote:
On 03/31/2015 07:37 AM, Carl George wrote:
How does this phrasing work for yall?
- If the repository has the potential to replace stock packages when
`yum update` is run, it must be disabled by default.
- If the repository is disabled by default, comments must be included
in the repo file to explain why.
That works for me :-)
+1 from me
This seems sane. It also helps protect from components that would not replace, but obsolete other components.
I have worked on this a bit more, fixed a few typos, and clarified some parts. In particular, I added a sentence pointing out that not all 3rd party repos necessarily work with each other. Here is the link again.
https://gist.github.com/cgtx/b854281462a18007f509
If no one has further suggestions for edits, what is the next step to make it official?
Carl George Rackspace RPM Development
________________________________________ From: centos-devel-bounces@centos.org centos-devel-bounces@centos.org on behalf of Nico Kadel-Garcia nkadel@gmail.com Sent: Monday, March 30, 2015 07:05 PM To: The CentOS developers mailing list. Subject: Re: [CentOS-devel] including 3rd party repo release RPMs in Extras
On Mon, Mar 30, 2015 at 3:44 PM, Manuel Wolfshant wolfy@nobugconsulting.ro wrote:
On 03/30/2015 10:29 PM, Peter wrote:
On 03/31/2015 07:37 AM, Carl George wrote:
How does this phrasing work for yall?
- If the repository has the potential to replace stock packages when
`yum update` is run, it must be disabled by default.
- If the repository is disabled by default, comments must be included
in the repo file to explain why.
That works for me :-)
+1 from me
This seems sane. It also helps protect from components that would not replace, but obsolete other components. _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 09.04.2015 15:34, Carl George wrote:
I have worked on this a bit more, fixed a few typos, and clarified some parts. In particular, I added a sentence pointing out that not all 3rd party repos necessarily work with each other. Here is the link again.
https://gist.github.com/cgtx/b854281462a18007f509
If no one has further suggestions for edits, what is the next step to make it official?
Well, you write:
"These repositories are still not associated with or supported by the CentOS project."
I don't think this is completely true: If you include them into "extras" you give some kind of support (ease of installation).
but maybe that's just me nitpicking.
just my 2 cents
kind regards
Sven
On 04/10/2015 01:34 AM, Carl George wrote:
I have worked on this a bit more, fixed a few typos, and clarified some parts. In particular, I added a sentence pointing out that not all 3rd party repos necessarily work with each other. Here is the link again.
https://gist.github.com/cgtx/b854281462a18007f509
If no one has further suggestions for edits, what is the next step to make it official?
Looks good to me. At this stage I think the only thing to add would be the actual instructions on how to get your -release file added to extras.
Peter
On Thu, Apr 9, 2015 at 5:10 PM, Peter peter@pajamian.dhs.org wrote:
On 04/10/2015 01:34 AM, Carl George wrote:
I have worked on this a bit more, fixed a few typos, and clarified some parts. In particular, I added a sentence pointing out that not all 3rd party repos necessarily work with each other. Here is the link again.
https://gist.github.com/cgtx/b854281462a18007f509
If no one has further suggestions for edits, what is the next step to make it official?
Looks good to me. At this stage I think the only thing to add would be the actual instructions on how to get your -release file added to extras.
It needs another rule, I thinkk:
* Stable packes do not *obsolete* packages from the standard repositories.
RHEL and CentOS in turn had serious conniptions when the 'ecj' package was named, and renamed, and obsoleted without cautious version settings for the packages being obsoleted. A lot of caution was needed for 'mysql-libs' by various vendors, and it's still a nasty hairball of a dependency for alternative MySQL or MariaDB installations. .
On 04/10/2015 12:17 PM, Nico Kadel-Garcia wrote:
It needs another rule, I thinkk:
* Stable packes do not *obsolete* packages from the standard repositories.
I don't personally have an issue with excluding packages that obsolete core packages, but I can't speak for everyone.
My main issue (that is now addressed) was to allow packages that replace core packages so long as the repo is disabled by default. The current language allows that and I'm happy with it.
Peter
On Thu, Apr 9, 2015 at 10:35 PM, Peter peter@pajamian.dhs.org wrote:
On 04/10/2015 12:17 PM, Nico Kadel-Garcia wrote:
It needs another rule, I thinkk:
* Stable packes do not *obsolete* packages from the standard repositories.I don't personally have an issue with excluding packages that obsolete core packages, but I can't speak for everyone.
I meant "by default". Thank you for clarifying that.
My main issue (that is now addressed) was to allow packages that replace core packages so long as the repo is disabled by default. The current language allows that and I'm happy with it.
Peter _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
As long as issue as the one describe by Remi will exist, it will be a bad idea.
IU is not safe for me
Regards
Hi,
Le 28/03/2015 21:32, Carl George a écrit :
CentOS users have easy access to the EPEL repo because the epel-release RPM is in the CentOS Extras repository. Obviously CentOS and EPEL have a special relationship, since they are both sponsored by Red Hat. A coworker suggested to me that it would be nice if the ius-release RPM could be included in Extras as well. I brought the idea up in IRC, and Karanbir suggested I draft up a specification that any third party repository can follow to be considered for inclusion. Here is what I have so far.
From above text.
* Must not automatically install, upgrade, or replace stock distribution packages when the repository is enabled.
Problem: lot of packages is repositories following this RFC provides the same "virtual" to be able to be a drop-in alternative for base packages.
Ex:
$ rpm -qp --provides php-mysql-5.3.3-40.el6_6.x86_64.rpm php-mysql = 5.3.3-40.el6_6 php-mysqli ...
$ rpm -qp --provides php56u-mysqlnd-5.6.7-1.ius.el6.x86_64.rpm php-mysql = 5.6.7-1.ius.el6 php-mysqli = 5.6.7-1.ius.el6 ...
What happen if someone (or a package dep.) try to pull php-mysqli ? Yum is unable to select the correct package.
So the rule, from the RFC is not honored.
More, there is a lot of 3rd party repository, most of them are not designed to be compatible with others (usually only with base + epel).
Sometime, users install a lot of these 3rd party repositories, and create terrible mess in their system. If CentOS is going to add "some" 3rd party repositories configuration, I think this will encourage users to enable them, and thus result in more mess.
Remi.
P.S. exemple of such issue, on an fresh C6 installation:
# yum --enablerepo=ius install phpMyAdmin ... Resolving Dependencies --> Running transaction check ---> Package phpMyAdmin.noarch 0:4.0.10.5-1.el6 will be installed --> Processing Dependency: php-mysql >= 5.2.0 for package: phpMyAdmin-4.0.10.5-1.el6.noarch --> Processing Dependency: php-mcrypt >= 5.2.0 for package: phpMyAdmin-4.0.10.5-1.el6.noarch --> Processing Dependency: php-mbstring >= 5.2.0 for package: phpMyAdmin-4.0.10.5-1.el6.noarch --> Processing Dependency: php-gd >= 5.2.0 for package: phpMyAdmin-4.0.10.5-1.el6.noarch --> Processing Dependency: php(language) >= 5.2.17 for package: phpMyAdmin-4.0.10.5-1.el6.noarch --> Processing Dependency: php-zlib for package: phpMyAdmin-4.0.10.5-1.el6.noarch --> Processing Dependency: php-zip for package: phpMyAdmin-4.0.10.5-1.el6.noarch --> Processing Dependency: php-xmlwriter for package: phpMyAdmin-4.0.10.5-1.el6.noarch --> Processing Dependency: php-tcpdf-dejavu-sans-fonts for package: phpMyAdmin-4.0.10.5-1.el6.noarch --> Processing Dependency: php-tcpdf for package: phpMyAdmin-4.0.10.5-1.el6.noarch --> Processing Dependency: php-spl for package: phpMyAdmin-4.0.10.5-1.el6.noarch --> Processing Dependency: php-simplexml for package: phpMyAdmin-4.0.10.5-1.el6.noarch --> Processing Dependency: php-session for package: phpMyAdmin-4.0.10.5-1.el6.noarch --> Processing Dependency: php-php-gettext for package: phpMyAdmin-4.0.10.5-1.el6.noarch --> Processing Dependency: php-pcre for package: phpMyAdmin-4.0.10.5-1.el6.noarch --> Processing Dependency: php-mysqli for package: phpMyAdmin-4.0.10.5-1.el6.noarch --> Processing Dependency: php-libxml for package: phpMyAdmin-4.0.10.5-1.el6.noarch --> Processing Dependency: php-json for package: phpMyAdmin-4.0.10.5-1.el6.noarch --> Processing Dependency: php-iconv for package: phpMyAdmin-4.0.10.5-1.el6.noarch --> Processing Dependency: php-hash for package: phpMyAdmin-4.0.10.5-1.el6.noarch --> Processing Dependency: php-filter for package: phpMyAdmin-4.0.10.5-1.el6.noarch --> Processing Dependency: php-date for package: phpMyAdmin-4.0.10.5-1.el6.noarch --> Processing Dependency: php-curl for package: phpMyAdmin-4.0.10.5-1.el6.noarch --> Processing Dependency: php-ctype for package: phpMyAdmin-4.0.10.5-1.el6.noarch --> Processing Dependency: php-bz2 for package: phpMyAdmin-4.0.10.5-1.el6.noarch --> Running transaction check ---> Package php-common.x86_64 0:5.3.3-40.el6_6 will be installed ---> Package php-php-gettext.noarch 0:1.0.11-3.el6 will be installed ---> Package php-tcpdf.noarch 0:6.0.095-1.el6 will be installed --> Processing Dependency: php-tidy for package: php-tcpdf-6.0.095-1.el6.noarch --> Processing Dependency: php-bcmath for package: php-tcpdf-6.0.095-1.el6.noarch --> Processing Dependency: /usr/bin/php for package: php-tcpdf-6.0.095-1.el6.noarch ---> Package php-tcpdf-dejavu-sans-fonts.noarch 0:6.0.095-1.el6 will be installed ---> Package php56u-common.x86_64 0:5.6.2-3.ius.el6 will be installed --> Processing Dependency: php56u-pecl-jsonc(x86-64) for package: php56u-common-5.6.2-3.ius.el6.x86_64 ---> Package php56u-gd.x86_64 0:5.6.2-3.ius.el6 will be installed ---> Package php56u-mbstring.x86_64 0:5.6.2-3.ius.el6 will be installed ---> Package php56u-mcrypt.x86_64 0:5.6.2-3.ius.el6 will be installed ---> Package php56u-mysqlnd.x86_64 0:5.6.2-3.ius.el6 will be installed --> Processing Dependency: php56u-pdo = 5.6.2-3.ius.el6 for package: php56u-mysqlnd-5.6.2-3.ius.el6.x86_64 ---> Package php56u-xml.x86_64 0:5.6.2-3.ius.el6 will be installed --> Running transaction check ---> Package php-bcmath.x86_64 0:5.3.3-40.el6_6 will be installed ---> Package php-cli.x86_64 0:5.3.3-40.el6_6 will be installed ---> Package php-tidy.x86_64 0:5.3.3-40.el6_6 will be installed ---> Package php56u-pdo.x86_64 0:5.6.2-3.ius.el6 will be installed ---> Package php56u-pecl-jsonc.x86_64 0:1.3.6-3.ius.el6 will be installed --> Processing Dependency: php56u-pear for package: php56u-pecl-jsonc-1.3.6-3.ius.el6.x86_64 --> Processing Dependency: php56u-pear for package: php56u-pecl-jsonc-1.3.6-3.ius.el6.x86_64 --> Running transaction check ---> Package php56u-pear.noarch 1:1.9.5-1.ius.el6 will be installed --> Processing Dependency: php56u-posix for package: 1:php56u-pear-1.9.5-1.ius.el6.noarch --> Processing Dependency: php56u-cli for package: 1:php56u-pear-1.9.5-1.ius.el6.noarch --> Running transaction check ---> Package php56u-cli.x86_64 0:5.6.2-3.ius.el6 will be installed ---> Package php56u-process.x86_64 0:5.6.2-3.ius.el6 will be installed --> Processing Conflict: php56u-cli-5.6.2-3.ius.el6.x86_64 conflicts php-cli < 5.6 --> Processing Conflict: php56u-common-5.6.2-3.ius.el6.x86_64 conflicts php-common < 5.6 --> Finished Dependency Resolution Error: php56u-common conflicts with php-common-5.3.3-40.el6_6.x86_64 Error: php56u-cli conflicts with php-cli-5.3.3-40.el6_6.x86_64 You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest
Perhaps the wording can be better on that rule (suggestions?), but the spirit of that rule is "What happens when I run `yum update`?" I don't see your example as conflicting with that rule. You can easily resolve that example by installing the desired php stack first, and then installing phpMyAdmin. It is less than ideal, but we have to work within the limitations of yum's dependency resolution.
We entertained the idea of having ius-release depend on yum-plugin-priorities, but since the default priority is 99, there is no way to have a new repo be a lower priority than a stock one. You would have to edit the base repo files to set them to a higher priority first.
Carl George Rackspace RPM Development
________________________________________ From: centos-devel-bounces@centos.org centos-devel-bounces@centos.org on behalf of Remi Collet Fedora@FamilleCollet.com Sent: Sunday, March 29, 2015 10:45 AM To: centos-devel@centos.org Subject: Re: [CentOS-devel] including 3rd party repo release RPMs in Extras
Hi,
Le 28/03/2015 21:32, Carl George a écrit :
CentOS users have easy access to the EPEL repo because the epel-release RPM is in the CentOS Extras repository. Obviously CentOS and EPEL have a special relationship, since they are both sponsored by Red Hat. A coworker suggested to me that it would be nice if the ius-release RPM could be included in Extras as well. I brought the idea up in IRC, and Karanbir suggested I draft up a specification that any third party repository can follow to be considered for inclusion. Here is what I have so far.
From above text.
* Must not automatically install, upgrade, or replace stock distribution packages when the repository is enabled.
Problem: lot of packages is repositories following this RFC provides the same "virtual" to be able to be a drop-in alternative for base packages.
Ex:
$ rpm -qp --provides php-mysql-5.3.3-40.el6_6.x86_64.rpm php-mysql = 5.3.3-40.el6_6 php-mysqli ...
$ rpm -qp --provides php56u-mysqlnd-5.6.7-1.ius.el6.x86_64.rpm php-mysql = 5.6.7-1.ius.el6 php-mysqli = 5.6.7-1.ius.el6 ...
What happen if someone (or a package dep.) try to pull php-mysqli ? Yum is unable to select the correct package.
So the rule, from the RFC is not honored.
More, there is a lot of 3rd party repository, most of them are not designed to be compatible with others (usually only with base + epel).
Sometime, users install a lot of these 3rd party repositories, and create terrible mess in their system. If CentOS is going to add "some" 3rd party repositories configuration, I think this will encourage users to enable them, and thus result in more mess.
Remi.
P.S. exemple of such issue, on an fresh C6 installation:
# yum --enablerepo=ius install phpMyAdmin ... Resolving Dependencies --> Running transaction check ---> Package phpMyAdmin.noarch 0:4.0.10.5-1.el6 will be installed --> Processing Dependency: php-mysql >= 5.2.0 for package: phpMyAdmin-4.0.10.5-1.el6.noarch --> Processing Dependency: php-mcrypt >= 5.2.0 for package: phpMyAdmin-4.0.10.5-1.el6.noarch --> Processing Dependency: php-mbstring >= 5.2.0 for package: phpMyAdmin-4.0.10.5-1.el6.noarch --> Processing Dependency: php-gd >= 5.2.0 for package: phpMyAdmin-4.0.10.5-1.el6.noarch --> Processing Dependency: php(language) >= 5.2.17 for package: phpMyAdmin-4.0.10.5-1.el6.noarch --> Processing Dependency: php-zlib for package: phpMyAdmin-4.0.10.5-1.el6.noarch --> Processing Dependency: php-zip for package: phpMyAdmin-4.0.10.5-1.el6.noarch --> Processing Dependency: php-xmlwriter for package: phpMyAdmin-4.0.10.5-1.el6.noarch --> Processing Dependency: php-tcpdf-dejavu-sans-fonts for package: phpMyAdmin-4.0.10.5-1.el6.noarch --> Processing Dependency: php-tcpdf for package: phpMyAdmin-4.0.10.5-1.el6.noarch --> Processing Dependency: php-spl for package: phpMyAdmin-4.0.10.5-1.el6.noarch --> Processing Dependency: php-simplexml for package: phpMyAdmin-4.0.10.5-1.el6.noarch --> Processing Dependency: php-session for package: phpMyAdmin-4.0.10.5-1.el6.noarch --> Processing Dependency: php-php-gettext for package: phpMyAdmin-4.0.10.5-1.el6.noarch --> Processing Dependency: php-pcre for package: phpMyAdmin-4.0.10.5-1.el6.noarch --> Processing Dependency: php-mysqli for package: phpMyAdmin-4.0.10.5-1.el6.noarch --> Processing Dependency: php-libxml for package: phpMyAdmin-4.0.10.5-1.el6.noarch --> Processing Dependency: php-json for package: phpMyAdmin-4.0.10.5-1.el6.noarch --> Processing Dependency: php-iconv for package: phpMyAdmin-4.0.10.5-1.el6.noarch --> Processing Dependency: php-hash for package: phpMyAdmin-4.0.10.5-1.el6.noarch --> Processing Dependency: php-filter for package: phpMyAdmin-4.0.10.5-1.el6.noarch --> Processing Dependency: php-date for package: phpMyAdmin-4.0.10.5-1.el6.noarch --> Processing Dependency: php-curl for package: phpMyAdmin-4.0.10.5-1.el6.noarch --> Processing Dependency: php-ctype for package: phpMyAdmin-4.0.10.5-1.el6.noarch --> Processing Dependency: php-bz2 for package: phpMyAdmin-4.0.10.5-1.el6.noarch --> Running transaction check ---> Package php-common.x86_64 0:5.3.3-40.el6_6 will be installed ---> Package php-php-gettext.noarch 0:1.0.11-3.el6 will be installed ---> Package php-tcpdf.noarch 0:6.0.095-1.el6 will be installed --> Processing Dependency: php-tidy for package: php-tcpdf-6.0.095-1.el6.noarch --> Processing Dependency: php-bcmath for package: php-tcpdf-6.0.095-1.el6.noarch --> Processing Dependency: /usr/bin/php for package: php-tcpdf-6.0.095-1.el6.noarch ---> Package php-tcpdf-dejavu-sans-fonts.noarch 0:6.0.095-1.el6 will be installed ---> Package php56u-common.x86_64 0:5.6.2-3.ius.el6 will be installed --> Processing Dependency: php56u-pecl-jsonc(x86-64) for package: php56u-common-5.6.2-3.ius.el6.x86_64 ---> Package php56u-gd.x86_64 0:5.6.2-3.ius.el6 will be installed ---> Package php56u-mbstring.x86_64 0:5.6.2-3.ius.el6 will be installed ---> Package php56u-mcrypt.x86_64 0:5.6.2-3.ius.el6 will be installed ---> Package php56u-mysqlnd.x86_64 0:5.6.2-3.ius.el6 will be installed --> Processing Dependency: php56u-pdo = 5.6.2-3.ius.el6 for package: php56u-mysqlnd-5.6.2-3.ius.el6.x86_64 ---> Package php56u-xml.x86_64 0:5.6.2-3.ius.el6 will be installed --> Running transaction check ---> Package php-bcmath.x86_64 0:5.3.3-40.el6_6 will be installed ---> Package php-cli.x86_64 0:5.3.3-40.el6_6 will be installed ---> Package php-tidy.x86_64 0:5.3.3-40.el6_6 will be installed ---> Package php56u-pdo.x86_64 0:5.6.2-3.ius.el6 will be installed ---> Package php56u-pecl-jsonc.x86_64 0:1.3.6-3.ius.el6 will be installed --> Processing Dependency: php56u-pear for package: php56u-pecl-jsonc-1.3.6-3.ius.el6.x86_64 --> Processing Dependency: php56u-pear for package: php56u-pecl-jsonc-1.3.6-3.ius.el6.x86_64 --> Running transaction check ---> Package php56u-pear.noarch 1:1.9.5-1.ius.el6 will be installed --> Processing Dependency: php56u-posix for package: 1:php56u-pear-1.9.5-1.ius.el6.noarch --> Processing Dependency: php56u-cli for package: 1:php56u-pear-1.9.5-1.ius.el6.noarch --> Running transaction check ---> Package php56u-cli.x86_64 0:5.6.2-3.ius.el6 will be installed ---> Package php56u-process.x86_64 0:5.6.2-3.ius.el6 will be installed --> Processing Conflict: php56u-cli-5.6.2-3.ius.el6.x86_64 conflicts php-cli < 5.6 --> Processing Conflict: php56u-common-5.6.2-3.ius.el6.x86_64 conflicts php-common < 5.6 --> Finished Dependency Resolution Error: php56u-common conflicts with php-common-5.3.3-40.el6_6.x86_64 Error: php56u-cli conflicts with php-cli-5.3.3-40.el6_6.x86_64 You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest
_______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
-
Carl George -
Les Mikesell -
Manuel Wolfshant -
Marianne Lombard -
Nico Kadel-Garcia -
Peter -
Remi Collet -
Sven Kieske