[opensuse-factory] Converting server:php:applications packages to require version agnostic virtual php packages

newer
[opensuse-factory] New Tumbleweed...

older
[opensuse-factory] Tumbleweed -...

Jimmy Berry

9 Dec 2015 9 Dec '15

11:01

I attempted to install the php7 package and noticed it does not replace/conflict with php5 and so it runs into a file conflict when installing. I added obsoletes to php7 package which behaves as desired. - https://build.opensuse.org/request/show/348020 I am not sure if there is a clean way to auto update all php5* packages with php7* packages where applicable. Next I noticed a number of php applications will be removed when updated to php7 which is due to hard dependency on php5 package. Many of the packages will work fine on php7 (or may in the future) and so I am working on changing them to php-foo virtual packages instead of php5-foo. I wrote a script to try and detect and fix basic *Require statements in .spec files. Will eventually create submit requests similar to: - https://build.opensuse.org/request/show/348017 - https://build.opensuse.org/request/show/348012 All work will be done in: - https://build.opensuse.org/project/show/home:boombatower:branches:server:php... Just a heads up in case others are working on this or considering it. Once I have an automated run I am happy with my plan is to do a fair bit of manual inspection and hopefully run a script to ensure same platforms fail to build as parent project and then run submit requests. Any suggests are appreciated. -- Jimmy -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Show replies by date

Jimmy Berry

9 Dec 9 Dec

13:21

New subject: [opensuse-factory] Re: Converting server:php:applications packages to require version agnostic virtual php packages

Working on cleaning up the 123 build failures related to removal of depdb. -- Jimmy On Wed, Dec 9, 2015 at 5:01 AM, Jimmy Berry wrote:

...

I attempted to install the php7 package and noticed it does not replace/conflict with php5 and so it runs into a file conflict when installing. I added obsoletes to php7 package which behaves as desired. - https://build.opensuse.org/request/show/348020

I am not sure if there is a clean way to auto update all php5* packages with php7* packages where applicable.

Next I noticed a number of php applications will be removed when updated to php7 which is due to hard dependency on php5 package. Many of the packages will work fine on php7 (or may in the future) and so I am working on changing them to php-foo virtual packages instead of php5-foo.

I wrote a script to try and detect and fix basic *Require statements in .spec files.

Will eventually create submit requests similar to: - https://build.opensuse.org/request/show/348017 - https://build.opensuse.org/request/show/348012

All work will be done in: - https://build.opensuse.org/project/show/home:boombatower:branches:server:php...

Just a heads up in case others are working on this or considering it. Once I have an automated run I am happy with my plan is to do a fair bit of manual inspection and hopefully run a script to ensure same platforms fail to build as parent project and then run submit requests.

Any suggests are appreciated.

-- Jimmy -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Jimmy Berry

14:53

New subject: [opensuse-factory] Re: Converting server:php:applications packages to require version agnostic virtual php packages

I have an automated fix that I am running in batches of 20 (out of 123 packages) and building in https://build.opensuse.org/package/show/home:boombatower:branches:server:php... prior to working on php7 stuff since it will be easier to confirm results without having to look for pre-existing package build failures. Not to mention we fix stuff too! I am not sure what procedure is, if any, as I will be generating a lot of submit requests between all these build failure fixes and then the php7 changes later. -- Jimmy On Wed, Dec 9, 2015 at 7:21 AM, Jimmy Berry wrote:

...

Working on cleaning up the 123 build failures related to removal of depdb.

-- Jimmy

On Wed, Dec 9, 2015 at 5:01 AM, Jimmy Berry wrote:

...
I attempted to install the php7 package and noticed it does not replace/conflict with php5 and so it runs into a file conflict when installing. I added obsoletes to php7 package which behaves as desired. - https://build.opensuse.org/request/show/348020

I am not sure if there is a clean way to auto update all php5* packages with php7* packages where applicable.

Next I noticed a number of php applications will be removed when updated to php7 which is due to hard dependency on php5 package. Many of the packages will work fine on php7 (or may in the future) and so I am working on changing them to php-foo virtual packages instead of php5-foo.

I wrote a script to try and detect and fix basic *Require statements in .spec files.

Will eventually create submit requests similar to: - https://build.opensuse.org/request/show/348017 - https://build.opensuse.org/request/show/348012

All work will be done in: - https://build.opensuse.org/project/show/home:boombatower:branches:server:php...

Just a heads up in case others are working on this or considering it. Once I have an automated run I am happy with my plan is to do a fair bit of manual inspection and hopefully run a script to ensure same platforms fail to build as parent project and then run submit requests.

Any suggests are appreciated.

-- Jimmy -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Bruno Friedmann

12 Dec 12 Dec

16:34

On Wednesday 09 December 2015 05.01:17 Jimmy Berry wrote:

...

I attempted to install the php7 package and noticed it does not replace/conflict with php5 and so it runs into a file conflict when installing. I added obsoletes to php7 package which behaves as desired. - https://build.opensuse.org/request/show/348020

I am not sure if there is a clean way to auto update all php5* packages with php7* packages where applicable.

Next I noticed a number of php applications will be removed when updated to php7 which is due to hard dependency on php5 package. Many of the packages will work fine on php7 (or may in the future) and so I am working on changing them to php-foo virtual packages instead of php5-foo.

I wrote a script to try and detect and fix basic *Require statements in .spec files.

Will eventually create submit requests similar to: - https://build.opensuse.org/request/show/348017 - https://build.opensuse.org/request/show/348012

All work will be done in: - https://build.opensuse.org/project/show/home:boombatower:branches:server:php...

Just a heads up in case others are working on this or considering it. Once I have an automated run I am happy with my plan is to do a fair bit of manual inspection and hopefully run a script to ensure same platforms fail to build as parent project and then run submit requests.

Any suggests are appreciated.

-- Jimmy

Just a question, before php7 will be considered as first choice, php5 will stay at least one or two years. Big projects will not be able to migrate quickly and would like to stay on php5. Isn't there a simple way to have update-alternatives packaging as it's done for python2 / python3 especially that php5 in /etc var/lib and so is already there, it can't have conflict with php7 derivative. Just a through -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch openSUSE Member & Board, fsfe fellowship GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Jimmy Berry

13 Dec 13 Dec

05:37

Unlike python 2 -> 2. php 5 -> 7 does not have major incompatibilities that should affect most projects. Short of some horrendous syntactically incorrect code that doesn't run in php 5 anyway that php 7 will complain about, there are only additional features, under the hood overhaul, and removal of features that had been deprecated for ages (like insecure mysql extensions). All of the personal projects I use were able to run on php 7 and generally seems to be the consensus online. If we want both to be installable alongside eachother then the php7 and perhaps php5 package needs to be updated to not share the same path. I do not think this is necessary and for something like Tumbleweed it seems reasonable to attempt and make it the default (obviously exploring for issues). The *requires changes I proposed will need to be made regardless since they make it impossible to use the compatible packages with php7 (held up waiting for resolution of 120+ build failures so it will be easier to verify). In general people should be able to just upgrade to php7. They went the more aggressive, break stuff route, with php6 and due to backlash and other problems they abandon that approach. As such php 7 should be generally compatible with both php code and extensions. -- Jimmy On Sat, Dec 12, 2015 at 10:34 AM, Bruno Friedmann wrote:

...

On Wednesday 09 December 2015 05.01:17 Jimmy Berry wrote:

...
I attempted to install the php7 package and noticed it does not replace/conflict with php5 and so it runs into a file conflict when installing. I added obsoletes to php7 package which behaves as desired. - https://build.opensuse.org/request/show/348020

I am not sure if there is a clean way to auto update all php5* packages with php7* packages where applicable.

Next I noticed a number of php applications will be removed when updated to php7 which is due to hard dependency on php5 package. Many of the packages will work fine on php7 (or may in the future) and so I am working on changing them to php-foo virtual packages instead of php5-foo.

I wrote a script to try and detect and fix basic *Require statements in .spec files.

Will eventually create submit requests similar to: - https://build.opensuse.org/request/show/348017 - https://build.opensuse.org/request/show/348012

All work will be done in: - https://build.opensuse.org/project/show/home:boombatower:branches:server:php...

Just a heads up in case others are working on this or considering it. Once I have an automated run I am happy with my plan is to do a fair bit of manual inspection and hopefully run a script to ensure same platforms fail to build as parent project and then run submit requests.

Any suggests are appreciated.

-- Jimmy

Just a question, before php7 will be considered as first choice, php5 will stay at least one or two years. Big projects will not be able to migrate quickly and would like to stay on php5.

Isn't there a simple way to have update-alternatives packaging as it's done for python2 / python3 especially that php5 in /etc var/lib and so is already there, it can't have conflict with php7 derivative.

Just a through

--

Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch

openSUSE Member & Board, fsfe fellowship GPG KEY : D5C9B751C4653227 irc: tigerfoot

-- 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

Jimmy Berry

05:42

python 2 -> 3** An example is that the previous version of Drupal (7) runs perfectly on php7 with dozens of addon modules (one of my test cases). -- Jimmy On Sat, Dec 12, 2015 at 11:37 PM, Jimmy Berry wrote:

...

Unlike python 2 -> 2. php 5 -> 7 does not have major incompatibilities that should affect most projects. Short of some horrendous syntactically incorrect code that doesn't run in php 5 anyway that php 7 will complain about, there are only additional features, under the hood overhaul, and removal of features that had been deprecated for ages (like insecure mysql extensions).

All of the personal projects I use were able to run on php 7 and generally seems to be the consensus online. If we want both to be installable alongside eachother then the php7 and perhaps php5 package needs to be updated to not share the same path. I do not think this is necessary and for something like Tumbleweed it seems reasonable to attempt and make it the default (obviously exploring for issues).

The *requires changes I proposed will need to be made regardless since they make it impossible to use the compatible packages with php7 (held up waiting for resolution of 120+ build failures so it will be easier to verify).

In general people should be able to just upgrade to php7. They went the more aggressive, break stuff route, with php6 and due to backlash and other problems they abandon that approach. As such php 7 should be generally compatible with both php code and extensions.

-- Jimmy

On Sat, Dec 12, 2015 at 10:34 AM, Bruno Friedmann wrote:

...
On Wednesday 09 December 2015 05.01:17 Jimmy Berry wrote:

...
I attempted to install the php7 package and noticed it does not replace/conflict with php5 and so it runs into a file conflict when installing. I added obsoletes to php7 package which behaves as desired. - https://build.opensuse.org/request/show/348020

I am not sure if there is a clean way to auto update all php5* packages with php7* packages where applicable.

Next I noticed a number of php applications will be removed when updated to php7 which is due to hard dependency on php5 package. Many of the packages will work fine on php7 (or may in the future) and so I am working on changing them to php-foo virtual packages instead of php5-foo.

I wrote a script to try and detect and fix basic *Require statements in .spec files.

Will eventually create submit requests similar to: - https://build.opensuse.org/request/show/348017 - https://build.opensuse.org/request/show/348012

All work will be done in: - https://build.opensuse.org/project/show/home:boombatower:branches:server:php...

Just a heads up in case others are working on this or considering it. Once I have an automated run I am happy with my plan is to do a fair bit of manual inspection and hopefully run a script to ensure same platforms fail to build as parent project and then run submit requests.

Any suggests are appreciated.

-- Jimmy

Just a question, before php7 will be considered as first choice, php5 will stay at least one or two years. Big projects will not be able to migrate quickly and would like to stay on php5.

Isn't there a simple way to have update-alternatives packaging as it's done for python2 / python3 especially that php5 in /etc var/lib and so is already there, it can't have conflict with php7 derivative.

Just a through

--

Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch

openSUSE Member & Board, fsfe fellowship GPG KEY : D5C9B751C4653227 irc: tigerfoot

-- 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

Bruno Friedmann

07:47

On Saturday 12 December 2015 23.42:16 Jimmy Berry wrote:

...

python 2 -> 3**

An example is that the previous version of Drupal (7) runs perfectly on php7 with dozens of addon modules (one of my test cases).

-- Jimmy

On Sat, Dec 12, 2015 at 11:37 PM, Jimmy Berry wrote:

...
Unlike python 2 -> 2. php 5 -> 7 does not have major incompatibilities that should affect most projects. Short of some horrendous syntactically incorrect code that doesn't run in php 5 anyway that php 7 will complain about, there are only additional features, under the hood overhaul, and removal of features that had been deprecated for ages (like insecure mysql extensions).

All of the personal projects I use were able to run on php 7 and generally seems to be the consensus online. If we want both to be installable alongside eachother then the php7 and perhaps php5 package needs to be updated to not share the same path. I do not think this is necessary and for something like Tumbleweed it seems reasonable to attempt and make it the default (obviously exploring for issues).

The *requires changes I proposed will need to be made regardless since they make it impossible to use the compatible packages with php7 (held up waiting for resolution of 120+ build failures so it will be easier to verify).

In general people should be able to just upgrade to php7. They went the more aggressive, break stuff route, with php6 and due to backlash and other problems they abandon that approach. As such php 7 should be generally compatible with both php code and extensions.

-- Jimmy

Excellent news :-) And many many thanks to take care of the builds errors and so one on OBS This is really appreciate. Long live to php7 :-) -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch openSUSE Member & Board, fsfe fellowship GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Jimmy Berry

14 Dec 14 Dec

01:12

With this request I am happy with the php5 -> php7 package upgrade path: https://build.opensuse.org/request/show/348767. With this approach I was able to upgrade using one of the following methods: zypper dup (--from my repo since this isn't in factory) zypper in php7 (zypper provides a solution to vendor change to my php7 repo packages for each extension) Hopefully once factory request on php5 is accepted I can get back to fixing build errors and requires*. -- Jimmy On Sun, Dec 13, 2015 at 1:47 AM, Bruno Friedmann wrote:

...

On Saturday 12 December 2015 23.42:16 Jimmy Berry wrote:

...
python 2 -> 3**

An example is that the previous version of Drupal (7) runs perfectly on php7 with dozens of addon modules (one of my test cases).

-- Jimmy

On Sat, Dec 12, 2015 at 11:37 PM, Jimmy Berry wrote:

...
Unlike python 2 -> 2. php 5 -> 7 does not have major incompatibilities that should affect most projects. Short of some horrendous syntactically incorrect code that doesn't run in php 5 anyway that php 7 will complain about, there are only additional features, under the hood overhaul, and removal of features that had been deprecated for ages (like insecure mysql extensions).

All of the personal projects I use were able to run on php 7 and generally seems to be the consensus online. If we want both to be installable alongside eachother then the php7 and perhaps php5 package needs to be updated to not share the same path. I do not think this is necessary and for something like Tumbleweed it seems reasonable to attempt and make it the default (obviously exploring for issues).

The *requires changes I proposed will need to be made regardless since they make it impossible to use the compatible packages with php7 (held up waiting for resolution of 120+ build failures so it will be easier to verify).

In general people should be able to just upgrade to php7. They went the more aggressive, break stuff route, with php6 and due to backlash and other problems they abandon that approach. As such php 7 should be generally compatible with both php code and extensions.

-- Jimmy

Excellent news :-)

And many many thanks to take care of the builds errors and so one on OBS This is really appreciate.

Long live to php7 :-)

--

Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch

openSUSE Member & Board, fsfe fellowship GPG KEY : D5C9B751C4653227 irc: tigerfoot

-- 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

vetter＠physik.uni-wuerzburg.de

15 Dec 15 Dec

10:30

...

With this request I am happy with the php5 -> php7 package upgrade path: https://build.opensuse.org/request/show/348767.

With this approach I was able to upgrade using one of the following methods:

zypper dup (--from my repo since this isn't in factory) zypper in php7 (zypper provides a solution to vendor change to my php7 repo packages for each extension)

Hopefully once factory request on php5 is accepted I can get back to fixing build errors and requires*.

On Sun, Dec 13, 2015 at 1:47 AM, Bruno Friedmann wrote:

...
On Saturday 12 December 2015 23.42:16 Jimmy Berry wrote:

...
python 2 -> 3**

An example is that the previous version of Drupal (7) runs perfectly on php7 with dozens of addon modules (one of my test cases).

On Sat, Dec 12, 2015 at 11:37 PM, Jimmy Berry wrote:

...
Unlike python 2 -> 2. php 5 -> 7 does not have major incompatibilities that should affect most projects. Short of some horrendous syntactically incorrect code that doesn't run in php 5 anyway that

...

...
...
...
7 will complain about, there are only additional features, under

...

...
...
...
hood overhaul, and removal of features that had been deprecated for ages (like insecure mysql extensions).

All of the personal projects I use were able to run on php 7 and generally seems to be the consensus online. If we want both to be installable alongside eachother then the php7 and perhaps php5

j.boombatower@gmail.com wrote on 14/12/2015 02:12:03: php the package

...

...
...
...
needs to be updated to not share the same path. I do not think this is necessary and for something like Tumbleweed it seems reasonable to attempt and make it the default (obviously exploring for issues).

The *requires changes I proposed will need to be made regardless since they make it impossible to use the compatible packages with php7 (held up waiting for resolution of 120+ build failures so it will be easier to verify).

In general people should be able to just upgrade to php7. They went the more aggressive, break stuff route, with php6 and due to backlash and other problems they abandon that approach. As such php 7 should be generally compatible with both php code and extensions.

-- Jimmy

Excellent news :-)

And many many thanks to take care of the builds errors and so one on OBS This is really appreciate.

Long live to php7 :-)

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. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Ralf Lang

16 Dec 16 Dec

13:17

...

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... -- Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: lang@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

vetter＠physik.uni-wuerzburg.de

17 Dec 17 Dec

08:20

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

Jimmy Berry

09:11

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

Jimmy Berry

21 Dec 21 Dec

04:27

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

Jimmy Berry

08:50

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 wrote:

...

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

3055

Age (days ago)

3067

Last active (days ago)

List overview

Download

13 comments

4 participants

participants (4)

Bruno Friedmann
Jimmy Berry
Ralf Lang
vetter＠physik.uni-wuerzburg.de

[opensuse-factory] Converting server:php:applications packages to require version agnostic virtual php packages

tags

participants (4)