Alright! I implemented the sles_version condition removal (with safety
check that it will not touch it if more than just php53 references).
Also manual review or SRs. Additionally dropped the PreReq (with php5)
which the obs docs say should be dropped anyway and they have php5
references in a few packages which messing things up.
Scrapped working copy and
home:boombatower:branches:server:php:applications project. I then ran
the script against the 314 (of 345) packages that have a php5
reference in them. I may look into the remaining ones to see if they
are all good.
I disabled building while script branched and made changes to avoid
needless churn, but once completed I re-enabled and watch obs build
away!
See my branch project for full set of modified packages:
https://build.opensuse.org/project/show/home:boombatower:branches:server:php....
I then generated a full link diff (14,000 lines)
https://gist.github.com/boombatower/27124d17a1c5fe0246b6 and manually
scanned. At a glance the diff looked fine, but I'll take a look again
tomorrow (feel free to help). I'll let everything build overnight and
with luck I'll start sending the SRs tomorrow. I expect the monitor
page to was equal and significantly better since fixing preexisting
while making things php7 compatible.
Feel free to take a look and send SRs for anything odd.
Fun extra stuff:
- took ~2.5 hours to run script
- an abridged video of the process (because who doesn't like using
obs-studio, blender, and ffmpeg):
https://www.youtube.com/watch?v=OuzmO8boPdU.
- I believe a good chunk of the obs queue spike was when I enabled
builds for my branch repo: http://i.imgur.com/yazrlhC.png.
--
Jimmy
On Sun, Dec 20, 2015 at 10:27 PM, Jimmy Berry
On the topic of php53 for SLE builds, that appears mostly due to packages depending on php5-pear-channel-doctrine and such which explicitly list php5. That will naturally be solved by using version agnostic php package.
The other packages like composer that seem to have a needless rule for php53. It appears this way since I changed the other ones from php5 -> php again making this pointless. It can be cleaned up as follows and still builds fine for all versions.
@@ -38,13 +38,8 @@ #Requires: php-pear-jsonlint >= 1.0 #Requires: php-pear-json-schema >= 1.3 BuildArch: noarch -%if 0%{?sles_version} >= 10 -BuildRequires: php53 >= 5.3.2 -Requires: php53 >= 5.3.2 -%else BuildRequires: php >= 5.3.2 Requires: php >= 5.3.2 -%endif
%description Composer is a dependency manager tracking local dependencies of your projects
If possible I will look into automating those, but not necessary as it works either way.
On the larger topic, now that server:php:applications has mostly rebuilt we can see the build errors are all gone so I can proceed unencumbered. I created a repo to test out the approach and build against php7 for >= SLE_12 / openSUSE 13.1 while SLE_11_SP3 and SP4 build against php5. This should resemble the world when we have some building against php5 and php7 based on php7 being in factory.
The problem is that the solver is provided two options to fulfill php
5.3.3 (or similar): php5 or php7. One solution would be to conditionally buildrequires php7 for factory/tumbleweed, but that will end up with the same problem down the road (with php8). Two better solutions would seem to be either a) stop making phpN packages and just have a php package like kernel/Mesa/etc, but seems people will still probably want to be able to choose. Although the choice could still be done by adding devel:lang:phpN and setting that repo as higher priority. This seems unlikely to happen since a big change, but worth considering.
In the meantime we can mitigate the problem using prjconf (see https://build.opensuse.org/project/prjconf/home:boombatower:server:php7:appl...).
Prefer: php7 Prefer: php7-bcmath Prefer: php7-bz2 Prefer: php7-calendar ... [for the core php7 packages]
For the repos that do not have php7 this still degrades as expected and using php5 or php53. For non-build usage (ie end-user installs) the upgrade path is already handled and should be automatic in Tumbleweed if the php7 package is added. I fixed this in https://build.opensuse.org/request/show/348767.
So assuming everyone is onboard I'll start sending out the php agnostic requires/provides SRs. Once complete building against php7 can be verified by branching all/some of the packages into a repo with php7 and the prjconf as shown above.
Assuming php7 is then added to factory the s:p:a prjconf should be updated prior to that to avoid the solver issues.
-- Jimmy
On Thu, Dec 17, 2015 at 3:11 AM, Jimmy Berry
wrote: I was waiting for https://build.opensuse.org/request/show/347167 to be accepted and server:php:applications to rebuild. Once I see remaining failures, I'll work on those.
After that's all out of the way I'll run my script and submit requests to use agnostic deps on the remaining packages.
Final step will be to build all packages against php7 and perhaps perform some basic sanity checks on runtime.
obs is grinding through the backlog right now and I'm working on some mesa stuff, but I'll get back to it.
Assuming that all works out as expect I'll talk to php7 maintainer about submission to factory and look to see it made default.
-- Jimmy
On Thu, Dec 17, 2015 at 2:20 AM,
wrote: Ralf Lang
wrote on 16/12/2015 14:17:02: Thanks Jimmy for this big effort. It is really great! I may be wrong, but I believe there is still some version dependency in the php-pear stuff. A lot of packages require "php5-pear" but the SLE11SP3 and 4 package only provides "php53-pear" and "php-pear", so a lot of packages don't build for SLE11. Would you be willing to fix that, too?
Thanks again, Andreas.
Which packages are these? I run quite a few s:p:a libraries on SLES...
I'm basically interested in the phpunit* packages. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org