Bug 717158

Yury is completely right. Very annoying and non-systematic.
David Hrbáč

Thanks for the report.

You are welcome. Please let me know if there is anything else I can do to help.

Opening service tickets in the Red Hat customer portal should be helpful as
RHEL is mostly customer-driven.

Thank you for taking the time to enter a bug report with us. We do
appreciate the feedback and look to use reports such as this to guide our
efforts at improving our products. That being said, this bug tracking
system is not a mechanism for getting support, and as such we are not able
to make any guarantees as to the timeliness or suitability of a
resolution. If this issue is critical or in any way time sensitive, please
raise a ticket through your regular Red Hat support channels to make
certain that it gets the proper attention and prioritization to assure a
timely resolution.

For information on how to contact the Red Hat production support team,
please see:
https://www.redhat.com/support/process/production/#howto

Hi!

This issue is not time-critical for me at this point, however, I did open Case 00512700 as per your suggestion.

Thanks!

The issue here is that php53 provides php53 instead of provides php.  This is a complex problem to solve if you take into consideration that other RPMs may require a specific PHP API, and I have seen this problem myself.

Unfortunately I'm not sure of a way to solve it aside from shipping all php-dependent RPMs in parallel.  Ex: wordpress and wordpress53, where the latter requires "php53" and not "php".

While this is a problem in and of itself, perhaps this is indicative of a larger problem with yum/rpm, in that it cannot interpret "acceptable alternatives."  For example, what about the situation currently with MySQL and forks?  It is possible that someone could install an API-compatible MySQL RPM, but not be able to install something that depends on MySQL, because that package depends on "mysql" and not "mysql or alternative1 or alternative2".

Sorry, I don't mean to say that the reported issue is actually something different, but rather the reported issue is a smaller portion of the larger issue which is effectively handling multi-version streams of software within a specific major OS distribution version, a'la how RHEL maintains backwards-API/ABI compatibility through backporting, preventing, often times, the release of a newer version of shipped software.

Erik, not sure what you are getting at specifically there.

e.g. the php-api provide already exists (and is provided by both php53 and php in RHEL5), so packages could depend on that to say "I need a suitable version of PHP".  But the PHP "language API" requirement itself is not sufficient to capture the dependencies of something like wordpress... hence, this bug.

So then it sounds like packages that require php need to require a php api in some fashion, and not a specific version of the PHP package?

Erik, yes, ideally. The fact that php does provide versioned php-api allows me, for instance, to ship phpmyadmin packages that require a particular minimum version of PHP API, without actually depending upon a specific package version.

However, unfortunately, the *subpackages* of php do not have similar provides, so if, for instance, I need php-snmp for cacti, php53-snmp would not satisfy this requirement, so customers will be forced to have php instead of php53 on this server, unless a parallel cacti53 package is provided, which is of course a waste of resources.

So I'd like to support Joe here; the problem that you are talking about does exist, but I wouldn't say that the issue that I reported reduces to a subset of this larger generic problem of how rpm (does not) handle alternatives, which should to my mind be addressed separately.

I cannot update to recently released phpMyAdmin with yum update (I have php53-* packages installed instead of php-*):

--> Running transaction check
---> Package phpMyAdmin.noarch 0:2.11.11.3-2.el5 set to be updated
--> Processing Dependency: php-mcrypt >= 4.1.0 for package: phpMyAdmin
--> Processing Dependency: php-gd >= 4.1.0 for package: phpMyAdmin
--> Processing Dependency: php-mysql >= 4.1.0 for package: phpMyAdmin
--> Processing Dependency: php >= 4.1.0 for package: phpMyAdmin
--> Processing Dependency: php-mbstring >= 4.1.0 for package: phpMyAdmin
--> Running transaction check
---> Package php.x86_64 0:5.2.10-1.el5 set to be updated
--> Processing Dependency: php-cli = 5.2.10-1.el5 for package: php
--> Processing Dependency: php-common = 5.2.10-1.el5 for package: php
---> Package php-gd.x86_64 0:5.2.10-1.el5 set to be updated
---> Package php-mbstring.x86_64 0:5.2.10-1.el5 set to be updated
---> Package php-mcrypt.x86_64 0:5.2.9-2.el5.3 set to be updated
---> Package php-mysql.x86_64 0:5.2.10-1.el5 set to be updated
--> Processing Dependency: php-pdo for package: php-mysql
--> Running transaction check
---> Package php-cli.x86_64 0:5.2.10-1.el5 set to be updated
---> Package php-common.x86_64 0:5.2.10-1.el5 set to be updated
---> Package php-pdo.x86_64 0:5.2.10-1.el5 set to be updated
--> Processing Conflict: php53-common conflicts php-common
--> Finished Dependency Resolution
php53-common-5.3.3-1.el5_6.1.x86_64 from installed has depsolving problems
  --> php53-common conflicts with php-common
Error: php53-common conflicts with php-common

Well, that's exactly this problem... To be fair, I suspect that you are using EPEL, which is not officially supported by RH, because there is no phpMyAdmin package in RHEL shipped by Red Hat.

However, it's a nice illustration to the point that I'm making: for now maintainer-wise it's impossible to make a package foo such that it would work with both php and php53 on RHEL5 at the same time and the ugly workaround is to create and maintain a separate foo-php53 package, which is a waste of time.

Yury,

But, technically, that is a "separate" issue with RPM/packaging itself, and not necessarily the issue of this bug, which is that there are some packages that do not have the correct information in them... Right?

Erik,

That depends on what do you mean by "that is". Sorry if I missed your point, but it's not very clear to me where to draw the line. Let me explain you what I mean in more details:

If you are referring to comments 17/18 and by "that is" you mean the inability to install phpMyAdmin that Nerijus experienced, I wouldn't say that technically it's a separated issue from the one I opened the bug for.

I'd rather say that the lack of correct information in some packages leads to the problems of type described in comment #17, which is indeed the issue of this bug (and would be nice to have corrected irrespectively of the other issues) and is impossible to work around, because of 'a "separate" issue with RPM/packaging itself', if you would call it an issue.

See, I am by no means a specialist in packaging system design, but generally, when dealing with dependencies you can take two approaches. When you need to make a package that depends on some generic entity, e.g. an MTA:

1. You can make all packages that provide an MTA (exim, postfix, sendmail etc.) to declare that they `Provide: mail-transport-agent` and then depend your packages on 'mail-transport-agent' (`Requires: mail-transport-agent`).

2. You can make all packages that require an MTA explicitly list alternatives that they would accept (i.e. `Requires: sendmail >= 8.1 | postfix >= 2.3 | exim`).

As far as I understand, historically, RPM only had (1), but more powerful (1) and DEB had both (1) and (2), but (1) was less powerful. I'm saying 'more/less powerful', because in Debian you can't have versioned Provides unlike in RPM (see Debian Policy, section 7.1). If you want a kind of versioned Provides, you have to create an empty 'Debian native' meta-package instead.

On one hand, this kind of makes sense, because if you only use Provides for meta-entities, it doesn't make much sense to have it versioned, because sendmail, postfix and exim are not version/feature-aligned in any way, so you would never want to `Requires: mail-transport-agent >= 3.14`.

On the other hand, because in Debian you can't have versioned Provides (1), you can't provide something like php(api) = 3.14 and depend on this, but rather you'll have to specify the alternatives like in (2), or weed out certain certain packages (i.e. older versions of sendmail) by other means (Conflicts), or even create a versioned meta-package as described (introducing another layer of complexity).

If I understand you correctly, the question that you are raising is whether having only (1) in RPM is a generic design issue which should be regarded as a technically separate problem from having correct set of Provides in packages and subsequently corrected (in another bug).

My answer would be "It's not so obvious that it's an issue in the first place (and that it doesn't intersect with the question of having right Provides)", because in the ideal world, you have control over your packages (or have an understanding with a maintainer who has control over the packages), so that you can always rely on that the packages are declaring proper Provides that you can depend upon.

In this particular instance, this rule was broken and if we had (2) in RPM, yes, I agree, I could have used it as a workaround and the bug wouldn't be opened.

However, more flexibility leads to more entropy and I already see alternatives misused where meta-provides should have been declared. Also, I don't know what scenarios are covered by alternatives, that can't be covered with provides. This requires a serious discussion and a lot of thinking.

So, to make it short, it's complicated :-)

Are you trying to find out something specific, or you're just interested in getting a better understanding of the problem from an academic viewpoint?

I think it's all of the above.

- As you stated, there is no ability to "requires: a or b" right now with RPM. This means that a package providing some PHP solution canot "requires: php or php53"

- Packaging multiple versions of the same "program" to deal with inefficiencies in RPM is silly. Ex: wordpress and wordpress53 to deal with php/php53

- Packaging against some functionality could fix the issue, but then it requires that the original provider of the functionality actually set a correct provides, and for it to be as simple as that (in the case of something like the PHP API).

What I was suggesting "that is" was the issue with phpmyadmin, or, more generally, packages requiring "php".  The fix for issues like phpmyadmin, at present, is to package them twice with the corresponding requires, or to re-package them as requiring something like a PHP API version.  This is due to the fact that RPM, as a packaging tool, is limited in how you can specify things like provides/requires, and "that" is a separate issue from "this."  

"This" refers to the bug we are commenting on, which is about the php53 sub-packages not having any/the correct "provides" in their spec files.

Or, the short version -- issues with specific packages requiring PHP not being satisfied by PHP53 are unrelated to this bug (717158), which deals only with the lack of correct "provides" lines in php53 sub-packages.  Issues with specific packages requiring PHP not being satisfied by PHP53 are related to those packages alone, and can only be fixed by re-packaging or by "fixing" RPM to support more granular attributes.

(In reply to comment #21)
> - As you stated, there is no ability to "requires: a or b" right now with RPM.
> This means that a package providing some PHP solution canot "requires: php or
> php53"

Do you think doing something like this for EPEL5 packages requiring php would work:
https://bugzilla.redhat.com/show_bug.cgi?id=738105#c2

I haven't tested it yet

Hi Erik,

Sorry for the delay, I've got overloaded with outstanding tasks at $work and then have completely forgotten about this bug. 

(In reply to comment #21)
> I think it's all of the above.

Thanks for the explanation, it's much more clear to me now of what you mean. I mostly agree with everything you said apart from this conclusion:

> What I was suggesting "that is" was the issue with phpmyadmin, or, more
> generally, packages requiring "php".  The fix for issues like phpmyadmin, at
> present, is to package them twice with the corresponding requires, or to
> re-package them as requiring something like a PHP API version.  This is due to
> the fact that RPM, as a packaging tool, is limited in how you can specify
> things like provides/requires, and "that" is a separate issue from "this."  

If you had a closer look at the provided trace, you would have noticed that the 'phpmyadmin' issue stems exactly from this bug and *not* from a more generic problem that we were discussing.

The deal here is that phpmyadmin requires php-mysql and it is not provided by the php53 package (which makes it impossible to "package against some functionality" as you previously noted), hence php-common is being pulled in as a part of the dependency resolution cycle (because it does provide php-mysql) and, of course, it results into a conflict with php53-common.

So to my mind, this bug (#717158) is to be fixed ASAP irrespectively of anything else, which would alone solve a lot of practical problems for RH / EPEL, thrid-party packagers and RH customers.

The bigger and more generic 'Requires' issue warrants a wider discussion among the packagers, but my personal opinion is that given the analysis above, adding this feature will do more harm than good. I see it more as of a practical workaround that I could have applied in this case instead of getting the bug fixed upstream.

> - Packaging against some functionality could fix the issue, but then it
> requires that the original provider of the functionality actually set a correct
> provides, and for it to be as simple as that (in the case of something like the
> PHP API).

Just to make it clear, versioned 'Provides' have always been used exactly for this since day zero.

As I said, the only disadvantage of this solution (which you are calling an inefficiency of RPM) is that it puts the control in the hands of the upstream packager instead of the downstream packager. In this particular case, I filed the bug 3 months ago and subsequently a support case, but we're still nowhere near the end of the story.

Probably this is why Debian does it the other way around... but it doesn't mean that from the engineering standpoint it is technically a better solution. Socially, yes, most probably.

Z.

You are hurting my brain, but I believe that, at this point, I am in agreement with everything you have said.

I have cross-filled this issue as service request 00545700.

Right, we're running into this problem right now.  Basically, someone created the "provides" as %{name}, and set name to 'php53', so all "downstream" (sub-package) provides show up as:
 * php53, instead of php = 5.3.3
 * php53-mysql, instead of php-mysql = 5.3.3
 * php53-pdo, instead of php-pdo = 5.3.3
 * php53-pgsql, instead of php-pgsql = 5.3.3
 * php53-xml, instead of php-xml = 5.3.3
etc, etc, etc.

Because of this, any reliant packages (those that properly require things like 'php-mysql', etc.) will always fail due to the fact that the 'php53-*' packages never provide the right things.  For example, if my package requires 'php', 'php53', doesn't actually provide 'php.'  It only provides 'php53', which, of course, isn't equal to 'php'.

Looks like this was reported over 6 months ago...

(In reply to comment #29)
> 
> Looks like this was reported over 6 months ago...

I have heard from my rep. that it will make in RHEL 5.8. Let's hope so it will happen.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2012-0266.html

unfortunately this looks to be only partially fixed. the main php package doesn't provide php and php53-common doesn't provide php-common:

$ rpm -q --provides php53
config(php53) = 5.3.3-5.el5
libphp5.so()(64bit)  
mod_php = 5.3.3-5.el5
php53 = 5.3.3-5.el5

$ rpm -q --provides php53-common | grep common
config(php53-common) = 5.3.3-5.el5
php53-common = 5.3.3-5.el5

Hi,

I'm not sure if it's possible at all for php53-common to provide php-common, because in fact it explicitly conflicts with php-common from php, because php-common is being pulled in by php, whereas php53-common is being pulled in by php53.

I think that if php53-common was to provide versioned php-common, then the depresolver would always try to update php to php53 and other possible problems could arise if this provides is made unversioned.

My suggestion is hence to be more specific in your requirements and depend upon subpackages of php-common directly. Additionally, I don't see how it makes sense to depend upon php-common at all, because this package is always installed with php, so if you have packages that do so, they must be broken.

Z.

Yury is right.  What dependency are you trying to express, Jason?

Hi,

With regards to php53 not providing php, I'm afraid that again same problems
would ensue: upon request to install php, the depresolver would always try to
install php53 instead of php, because php53 provides php that is newer. I
didn't test it though, so I'm not 100% sure...

I think that if you want to depend upon php and you don't have specific version
requirements, you should depend upon php(api), since it's provided by both
packages, or just depend upon subpackages you need instead of direct dependency upon php.

Z.

ah ok, if the intention is to not have the provides for those two packages then it looks as if the problem I'm having is related to some EPEL packages, not the RHEL packages proper. anything that has the following won't function with the php53* packages:
  Requires: php >= VERSION
so far from the list of ones I have installed it looks like php-pear-HTTP, php-pear-XML-Beautifier, and php-pear-XML-Parser have that issue, and php-eaccelerator has a strict dep on the version of php-zend-abi, so it is problematic also. I'll open bugs against those packages, thx.

I can concur that this seems to still be a problem.

~/zcp-7.0.10-37482-rhel-5-x86_64]$ rpm -qa | grep rpm
rpm-python-4.4.2.3-28.el5_8
rpm-4.4.2.3-28.el5_8
rpm-libs-4.4.2.3-28.el5_8

~/zcp-7.0.10-37482-rhel-5-x86_64]$ rpm -i ./php-mapi-7.0.10-37482.x86_64.rpm 
error: Failed dependencies:
        php >= 5 is needed by php-mapi-7.0.10-37482.x86_64

~/zcp-7.0.10-37482-rhel-5-x86_64]$ rpm -q --provides php53
config(php53) = 5.3.3-13.el5_8
libphp5.so()(64bit)  
mod_php = 5.3.3-13.el5_8
php53 = 5.3.3-13.el5_8

~/zcp-7.0.10-37482-rhel-5-x86_64]$ rpm -q -R -p ./php-mapi-7.0.10-37482.x86_64.rpm  | grep php
config(php-mapi) = 7.0.10-37482
php >= 5

Now, this package (php-mapi) could probably be built with a requires for a PHP API:
~/zcp-7.0.10-37482-rhel-5-x86_64]$ rpm -q --provides php53-common | grep -e "api\|abi"
php(api) = 20090626
php(zend-abi) = 20090626
php-api = 20090626
php-zend-abi = 20090626

And, in this particular case, php-mapi would probably install.  But I still think it's a problem that the php53-common package does not provide php-common.

Thoughts?

Hi Erik,

I don't see your point. You took a module that is compiled for php and tried to install it on a system running php53. It failed to install. What's the problem? Re-compile it against php53, package it as php53-mapi and that's it.

Z.

If I'm understanding the whole thing correctly:

php53 provides php53 and not php
php53-common provides php53-common and not php-common

php53 -> php53-common + php53-mapi
php -> php-common + php-mapi

Easy, isn't it?

Erik,

Yes, this is correct, but what it has to do with your php-mapi problem? It doesn't install on your system for a different reason: php-mapi is a binary module compiled against an older Zend ABI/API.

$ rpm -q --provides php-common | grep -e "api\|abi"
php-api = 20041225
php-zend-abi = 20050922

The fact that php-mapi doesn't install on a system running php53 that provides newer API/ABI is a feature, not a bug. It should be recompiled against php53 first (and packaged as php53-mapi), then it will work.

Z.

The fact that php53 doesn't provide php > 5 is what I am saying is the bug, not the feature.

Erik, it is not a bug, it is a feature. We've already had a discussion about that a few comments earlier (see #33).

The solution is for the modules that would work for both php and php53 to have correct dependencies on API/ABI instead of the name of the package (php).