<div>On Thu, Mar 28, 2013 at 10:26:32PM -0400, Pat Barron wrote:<br>&gt; I notice that CentOS 5.9 packages PHP 5.3 as a separate &quot;thing&quot; - there<br>&gt; are &quot;php*&quot; packages, and &quot;php53*&quot; packages.</div>

<div><br></div><div>The &quot;php53&quot; (PHP 5.3) packageset in Red Hat Enterprise Linux Release 5 Update 6 and later (EL5.6+) [1] is a _conflicting_, &quot;rebase option&quot; (meaning changes from the original ABI/API, &quot;rebased&quot; from newer developments) from the original &quot;php&quot; (PHP 5.1) package set in the published, ten-plus (10+) year Red Hat Enterprise Linux Release 5 Application Binary/Programmer Interfaces (ABI/API).  So take care if you &quot;switch&quot; your PHP version, as some software may expect the original 5.1 modules to be loaded.</div>

<div><br></div><div> - Background</div><div><br></div><div>Understand any &quot;EL&quot; Life Cycle [2] involves extensive sustaining engineering to maintain that long-term ABI/API.  But during Phase I (first 5.5+ years) [2], Red Hat does take feature enhancement requests from customers.  So at times, Red Hat will release erratum Enhancement Advisories (RHEA), and they are usually a &quot;rebase option&quot; and many are &quot;concurrent options&quot; that do not conflict with the original version.  In some cases cases, the library (-lib) subpackages may not conflict and can often be concurrent, but clients/services/utilities (-client/-server/-tools) as well as header (-devel) subpackages may and often do conflict.</div>

<div><br></div><div>In the case of &quot;php53&quot; in EL5.6, without extensive reconfiguration, Apache does not allow multiple modules of different versions, hence the &quot;conflict.&quot;  A decision was made per customer requests to offer &quot;php53&quot; as an option, to synchronize with the same version as in Enterprise Linux Release 6 (EL6), with minimal modifications.</div>

<div><br></div><div><div>Such enhancement packages often have an abbreviated version is appended to the package name, so package names are usually &quot;(name)[(abbr-version)][-(subpackage)]-(full-version)-(release).(arch).&quot;</div>

<div><br></div></div><div>Again, Red Hat maintains very long-term ABI/API compatibility, and avoids rebasing to an extreme (10+ years).  Most other vendors do not do this beyond 3 years, and even some other &quot;Enterprise&quot; distributions rebase every 2-3, even if they support 5-7 overall.  E.g., even Attachmate (Novell-SuSE) has started rebasing more and more, including the kernel.  It&#39;s up to the _customer_ to decide which version to deploy, and the original version remains as long as it is feasible for Red Hat to keep sustaining it for years, separate from the upstream.</div>

<div><br></div><div>For more information on the &quot;core ABI/API&quot; of any &quot;EL&quot; release, see my &quot;Enterprise Linux Decoder Ring.&quot; [3]</div><div><br></div><div>&gt; Can they be installed in parallel?  Last thing we want to do is break a dependency that the wiki</div>

<div>&gt; has, or something.<br></div><div><br></div><div>No.  Again, it&#39;s one of the cases where a Red Hat Enhancement Advisor (RHEA) adds &quot;rebased&quot; packages can_not_ be &quot;concurrent&quot; with the original release.  It&#39;s up to the customer to decide if they want full, original compatibility or newer features.</div>

<div><br></div><div><br></div>On Sat, Mar 30, 2013 at 2:03 PM, Vance Kochenderfer <span dir="ltr">&lt;<a href="mailto:vkochend@nyx.net" target="_blank">vkochend@nyx.net</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im">It looks like the php53 packages are not designed to be installed</div>
parallel to php:</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Resolving Dependencies<br>
--&gt; Running transaction check<br>
---&gt; Package php53.i386 0:5.3.3-13.el5_8 set to be updated<br>
--&gt; Processing Dependency: php53-common = 5.3.3-13.el5_8 for package: php53<br>
--&gt; Processing Dependency: php53-cli = 5.3.3-13.el5_8 for package: php53<br>
--&gt; Running transaction check<br>
---&gt; Package php53-cli.i386 0:5.3.3-13.el5_8 set to be updated<br>
---&gt; Package php53-common.i386 0:5.3.3-13.el5_8 set to be updated<br>
--&gt; Processing Conflict: php53-common conflicts php-common<br>
--&gt; Finished Dependency Resolution<br>
php53-common-5.3.3-13.el5_8.i386 from base has depsolving problems<br>
  --&gt; php53-common conflicts with php-common<br>
Error: php53-common conflicts with php-common<br></blockquote><div><br></div><div>Or the original Red Hat Enhancement Advisory (RHEA) [1].</div><div><br></div><div>I cannot seem to locate the subsquent advisory from the &quot;downstream Enterprise Linux (EL) Rebuild&quot; [4] discussed here -- the equivalent advisory from the Community Enterprise Operating System (CentOS).  Anyone have the link handy?</div>

<div><br></div><div>I.e., I don&#39;t want to overstate when CentOS made this rebase available by assuming it was sometime shortly after Red Hat&#39;s erratum for EL5.6.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


I&#39;d have to check if there&#39;s any conflict between MediaWiki and<br>
PHP 5.3.  I would think it&#39;d probably work just fine but need to<br>
be sure.<br></blockquote><div><br></div><div>There are ABI/API changes between 5.1 and 5.3, hence why Red Hat considers it a rebase.</div><div><br></div><div>I don&#39;t know all of the details, but from personal experience, I noted a lot of customers were subscribing to the Oracle Technical Network (OTN) to get &quot;php&quot; packagesets of newer versions.  Of course, customers who subscribe to the OTN also often rebased to later &quot;php&quot; as well, among other programs.  I&#39;ve been pulled into dozens &quot;situations&quot; with Red Hat Global Support Services (GSS) where I was able to discover, on-site, they were tapping OTN, and that&#39;s why they had API/ABI breakage after such a rebase on OTN.</div>

<div><br></div><div>So, as always, take care to check these details before contacting your distribution provider&#39;s support.  I.e., make sure you&#39;re actually using their version, and not a 3rd party&#39;s.</div><div>

<br></div></div><div>--- bjs</div><br>[1] <a href="https://access.redhat.com/knowledge/articles/3078">https://access.redhat.com/knowledge/articles/3078</a><br><div>[2] <a href="https://access.redhat.com/support/policy/updates/errata/">https://access.redhat.com/support/policy/updates/errata/</a></div>

<div>[3] <a href="http://bjs-redhat.livejournal.com/4176.html">http://bjs-redhat.livejournal.com/4176.html</a><br></div><div>[4] <a href="http://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#Rebuilds">http://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#Rebuilds</a></div>

<div><br></div>