Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 400673 - php-5.2 removal
Summary: php-5.2 removal
Status: RESOLVED WONTFIX
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Development (show other bugs)
Hardware: All Linux
: Normal normal
Assignee: PHP Bugs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-01-25 01:47 UTC by Finn Thain
Modified: 2012-01-26 12:04 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Finn Thain 2012-01-25 01:47:48 UTC
Several days ago the php-5.2.17 ebuild was removed from the portage tree. This is a problem for those of us still hosting numerous web sites belonging to clients who have not yet qualified their code under any newer platform.

Like many others, we are obliged to support this platform in the short term. Fortunately, even though abandoned by its developers, php 5.2 is still maintained by various other distros.

Backported security and other bug fixes from CentOS and Debian are made available here -

  http://code.google.com/p/php52-backports/

I've tested this patch with Gentoo's php-5.2.17 ebuild and it builds and runs fine.

If users are obliged to maintain their own overlays then I fear that the Gentoo php eclasses and dependencies will ultimately prevent 5.2 and 5.3 co-existing, which would make migration even more difficult.

Please re-instate the php-5.2 ebuild with the backported fixes (for as long as it isn't a burden and fixes are readily available).

Reproducible: Always
Comment 1 Ole Markus With (RETIRED) gentoo-dev 2012-01-26 09:00:21 UTC
(In reply to comment #0)
> Several days ago the php-5.2.17 ebuild was removed from the portage tree. This
> is a problem for those of us still hosting numerous web sites belonging to
> clients who have not yet qualified their code under any newer platform.
> 

The removal was announced many months ago, then masked (also many months ago), and finally removed a few days ago. Yet this complaint comes now. Sorry, but this is a bit too late.

> 
> If users are obliged to maintain their own overlays then I fear that the Gentoo
> php eclasses and dependencies will ultimately prevent 5.2 and 5.3 co-existing,
> which would make migration even more difficult.
> 

You are quite right. We are already in the process of removing all code we have related to php 5.2 to make future versions of PHP easier to maintain.

> Please re-instate the php-5.2 ebuild with the backported fixes (for as long as
> it isn't a burden and fixes are readily available).
> 

It is a burden as soon as upstream stopped supporting the software. Our job as a distro is to distribute software and make sure it is compatible with related software we distribute. It is not our job to maintain software with no upstream support.

We simply do not have the resources to maintain three minor versions of PHP.
Comment 2 Finn Thain 2012-01-26 09:38:53 UTC
(In reply to comment #1)
> (In reply to comment #0)

> > If users are obliged to maintain their own overlays then I fear that the Gentoo
> > php eclasses and dependencies will ultimately prevent 5.2 and 5.3 co-existing,
> > which would make migration even more difficult.
> > 
> 
> You are quite right. We are already in the process of removing all code we have
> related to php 5.2 to make future versions of PHP easier to maintain.

If I put the old ebuild in an overlay, how long do I have before it breaks?

> 
> > Please re-instate the php-5.2 ebuild with the backported fixes (for as long as
> > it isn't a burden and fixes are readily available).
> > 
> 
> It is a burden as soon as upstream stopped supporting the software.

I would have thought that it became a burden when it was added to the tree.

> Our job as
> a distro is to distribute software and make sure it is compatible with related
> software we distribute. It is not our job to maintain software with no upstream
> support.
> 
> We simply do not have the resources to maintain three minor versions of PHP.

As I've lamented before, it is sad that distro's can't collaborate better.
Comment 3 Ole Markus With (RETIRED) gentoo-dev 2012-01-26 09:50:14 UTC
(In reply to comment #2)

> If I put the old ebuild in an overlay, how long do I have before it breaks?
> 

Difficult to say. Depends on how much we get done. A few months perhaps.
Comment 4 Matti Bickel (RETIRED) gentoo-dev 2012-01-26 10:01:21 UTC
I'm curious: we are removing PHP-5.2 from much of the DEPENDs these days, correct. But as a hosting provider, you probably test the software you provide (if any) to run with php-5.2 anyway. Or you have frozen your tree and run only glsa-check. Either way, how do you expect your ebuild for PHP-5.2 to break?

I'm not mocking you, or anything - if I know what would help you, I can take that into account when modifying the tree.
Comment 5 Finn Thain 2012-01-26 11:10:21 UTC
(In reply to comment #4)
> I'm curious: we are removing PHP-5.2 from much of the DEPENDs these days,
> correct. But as a hosting provider, you probably test the software you provide
> (if any) to run with php-5.2 anyway. Or you have frozen your tree and run only
> glsa-check. Either way, how do you expect your ebuild for PHP-5.2 to break?
> 
> I'm not mocking you, or anything - if I know what would help you, I can take
> that into account when modifying the tree.

I will copy the 5.2.17 ebuild into an overlay but I need to sync the rest of the tree. My concern is that I need the 5.2.17 ebuild to keep working installed simultaneously with present and future PHP ebuilds and eclasses (php-5.3 etc).

So I'm not particularly too worried about DEPENDs, but if they are accurate that would be good...
Comment 6 Michael Palimaka (kensington) gentoo-dev 2012-01-26 12:04:03 UTC
With regards to eclasses, I should note that they too can be placed in an overlay, affecting only ebuilds in that same overlay.
This would allow you to, for example, create a special overlay with just the versions of PHP, eclasses, and any associated bits and pieces you require to further minimise potential breakage.