Bug 738105 - drupal7 should require php >=5.2.5 rather than php53
Summary: drupal7 should require php >=5.2.5 rather than php53
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: drupal7
Version: el5
Hardware: Unspecified
OS: Unspecified
unspecified
low
Target Milestone: ---
Assignee: Gwyn Ciesla
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-09-13 23:47 UTC by Greg Swallow
Modified: 2017-03-10 15:01 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 704319
Environment:
Last Closed: 2017-03-10 15:01:19 UTC


Attachments (Terms of Use)

Description Greg Swallow 2011-09-13 23:47:06 UTC
The fix that was done as a result of the cloned bug report, to add:
Requires: php53, php53-gd, php53-mbstring, wget, php53-pdo, php53-xml
should in my opinion have been:
Requires: php >= 5.2.5, etc

If that doesn't work then file a bug report against the php53 rpm, don't make it that anyone that uses a set of php rpms named php-5.3 or php-5.4, etc rpms in years to come not be able to install this package.  In other words, require what is actually required.

+++ This bug was initially created as a clone of Bug #704319 +++

Description of problem:

Drupal 7 will not work with php < 5.2.5, also upstream recommend php 5.3

See: http://drupal.org/requirements#php

Comment 1 Paul W. Frields 2011-09-14 12:43:40 UTC
Unless the actual php53 packages in RHEL 5 (and clones) provide virtual capabilities like "php = 5.3", I don't see how this could work. And if the php53* packages were changed to do so, the php* packages for systems on all those distributions would be updated without warning to new versions, which isn't an acceptable outcome.

One workaround would be to make your custom php packages provide php53 (php53-gd, etc.).  I think this is an ugly hack.

The easier solution might be to simply customize our drupal7 package for yourself, which sounds feasible since you're obviously already using custom PHP packages.  Fortunately, our spec file is available for you which simplifies the process:
http://pkgs.fedoraproject.org/gitweb/?p=drupal7.git;a=tree;h=refs/heads/el5;hb=refs/heads/el5

I don't see another way to keep this package usable for the majority of EPEL users who are sticking with the vendor-maintained PHP stack.  The vendor-maintained php* and php53* stacks are very unlikely to deviate from their current versions, so using the verbatim requirement from Drupal would not be meaningful in the context of EPEL.

Although I'm going to close this bug WONTFIX as one of the co-maintainers, if you have an alternate suggestion that would not cause pain to all other systems using the php* and php53* packages, please feel free to reopen.  Thanks for filing this issue.

Comment 2 Greg Swallow 2011-09-14 23:10:00 UTC
How about change the drupal7 package to:
Requires: wget, drupal7-php525+

and package a subpackage on your EL5 build something like drupal7-php53 to be an empty rpm with this:
Requires: drupal7, php53-gd, php53-mbstring, wget, php53-pdo, php53-xml
Provides: drupal7-php525+

and another empty subpackage called drupal7-php with:
Requires: drupal7, php-gd >= 5.2.5, php-mbstring >= 5.2.5, php-pdo >=5.2.5, php-xml >= 5.2.5
Provides: drupal7-php525+

I think if someone does "yum install drupal7" it will choose to install drupal7-php53 as well on a RHEL/EPEL only system, and it will install drupal7-php as well on a RHEL/EPEL/famillecollet.com system...Sounds like it should work to me

Comment 3 Yury V. Zaytsev 2011-09-16 07:54:35 UTC
(In reply to comment #2)

> I think if someone does "yum install drupal7" it will choose to install
> drupal7-php53 as well on a RHEL/EPEL only system, and it will install
> drupal7-php as well on a RHEL/EPEL/famillecollet.com system...Sounds like it
> should work to me

Butt-ugly, but it would actually work. Another solution that comes to my mind would be to build 'shim' packages, providing all of the 'Provides' that RH has missed.

The problem that I see with both of those solutions is that if upstream ever fixes the bug for good, we would have to deal with the upgrade paths from these additional packages that we introduced as a temporary workaround, which will be surely very unpleasant.

All these Obsoletes and virtual Provides are a mess. That's why I'd highly appreciate you helping me to push RH to fix the original issue.

Please open support requests with them, explaining how it hurts your deployments, this would surely work... When there's only one support request on file, it's obviously not given enough priority.

Comment 4 Greg Swallow 2011-09-16 08:40:16 UTC
(In reply to comment #3)
> All these Obsoletes and virtual Provides are a mess. That's why I'd highly
> appreciate you helping me to push RH to fix the original issue.
> 
> Please open support requests with them, explaining how it hurts your
> deployments, this would surely work... When there's only one support request on
> file, it's obviously not given enough priority.

Unfortunatly I am a lowly CentOS & SME Server (uses rpms from CentOS) user, I have no clout with Redhat. 

I don't see a way how Redhat could fix the obsoletes and provides in php53, without causing any server with 5.1 to get a cue to update.  Hindsight being 20-20, they should have made a channel for php53 (and samba3x while we're at it) like I think they do for RHWAS which has php-5.2.10 rpms (not renamed), and then they wouldn't have had to rename them.

Comment 5 Yury V. Zaytsev 2011-09-16 08:50:32 UTC
(In reply to comment #4)

> I don't see a way how Redhat could fix the obsoletes and provides in php53,
> without causing any server with 5.1 to get a cue to update.

Very easy, as I noted in the other bug, all they have to do is to add correct versioned provides to the php53 package ('Provides: php-mysql = 5.3' etc.) and put versioned requires into the php package, so that php/php53 packages wouldn't mix up.

> Hindsight being 20-20, they should have made a channel for php53 (and samba3x
> while we're at it) like I think they do for RHWAS which has php-5.2.10 rpms
> not renamed), and then they wouldn't have had to rename them.

Agreed, especially since php53 is not parallel-installable with php anyways. Going for php53 was not a very considerate decision.

Comment 6 Paul W. Frields 2011-09-21 20:19:54 UTC
(In reply to comment #5)
> (In reply to comment #4)
> 
> > I don't see a way how Redhat could fix the obsoletes and provides in php53,
> > without causing any server with 5.1 to get a cue to update.
> 
> Very easy, as I noted in the other bug, all they have to do is to add correct
> versioned provides to the php53 package ('Provides: php-mysql = 5.3' etc.) and
> put versioned requires into the php package, so that php/php53 packages
> wouldn't mix up.

That won't work.  Packages that require only "php" and not a specific version of php will automatically be asked to update to the new one.

Comment 7 Yury V. Zaytsev 2011-09-21 20:29:31 UTC
(In reply to comment #6).
> 
> That won't work.  Packages that require only "php" and not a specific version
> of php will automatically be asked to update to the new one.

Could you please explain more exactly of what do you mean by this?

Comment 8 Paul W. Frields 2011-09-22 14:42:00 UTC
Imagine some third-party (or even Red Hat provided) package frobozz has this:

  Requires: php-mysql

Assume that when the third party created the package, they did so expecting the original 5.1.x release of php-mysql.  If as suggested, the php53-mysql package has:

  Provides: php-mysql = 5.3

...then when someone installs my frobozz package on a system without any stack, they will receive the php53-mysql package instead of php-mysql, which is unexpected.  That's just how version comparison happens, so this fix won't work AFAICT.  And in fact I believe this would also cause *existing* installations of frobozz + php-mysql to also receive the php53-mysql update, which would be equally incorrect to do.  Equally troublesome are the already mentioned issues with upgrade paths.

Comment 9 Yury V. Zaytsev 2011-09-22 14:53:53 UTC
(In reply to comment #8)
> Assume that when the third party created the package, they did so expecting the
> original 5.1.x release of php-mysql.  If as suggested, the php53-mysql package
> has:
> 
>   Provides: php-mysql = 5.3

Hmmm, I guess that you are right, I should have said instead:

   Provides: php-mysql

Versioned Provides: for php-mysql in particular doesn't make sense, because packages should rather depend on a correct version of php(api).

The problem is, however, that

   Provides: php-mysql

is not there at all, hence this bug (see bug #717158).

Comment 10 Gwyn Ciesla 2017-03-10 15:01:19 UTC
On March 31, 2017, Red Hat Enterprise Linux (RHEL) 5 will move out of
"Production Phase 3". At this point various rebuilds will be ending
support for EL-5 and EPEL will be archiving EPEL-5.

What this means is the following:
1. EPEL-5 (/pub/epel/5/, /pub/epel/testing/5/) will be copied to
/pub/archive/epel/5.
2. Mirrors that mirror archives will pick up EPEL-5 in it new location.
3. Mirrormanager will point to those location as the canonical places.
4. Koji will be set to no compose for EPEL-5. This effectively stops
builds from getting 'pushed' to the trees.
5. The data in /pub/epel/5 and /pub/epel/testing/5/ will be removed
and will disappear from mirrors.

Because 2017-03-31 is a Friday, these changes will occur during the next week.


Note You need to log in before you can comment on or make changes to this bug.