Debian Jessie dependencies/conflicts

[depekavie]

I suggest to adapt the Debian Jessie dependencies for php7.0*, to "Provides: php5" and "Replaces: php5" (and alike for -cgi, -common, -cli, -fpm).

Otherwise the installation of php7.0 may break several other packages, that are otherwise probably supposed to work with php7.0.

Of course:
php7.0 (7.0.0-1dotdeb+8.1) conflicts with php5 (5.6.14+dfsg-0+deb8u1)
php7.0-cgi (7.0.0-1dotdeb+8.1 conflicts with php5-cgi 5.6.14+dfsg-0+deb8u1)

removing php5 will lead to broken dependencies for php-auth-sasl and php-net-sieve.
removing php7.0-cgi will break dependencies for froxlor (not from debian repositories); it demands for either php5 or php5-cgi.
The same will happen with squirrelmail 2:1.4.23~svn20120406-2. (I can live with that...)
Removing php5-common will then lead to the suggestion for removal of 33 other packages in my case. Among them are:
drush 5.10.0-2 and phpmyadmin 4:4.2.12-2+deb

Thanks!

[gplessis]

Unfortunately, I can't test and rebuild all the packages depending on php5 to make them compatible with php7.0 packages. Especially web apps.

So yes, as you did, I could modify the php7.0 packages to :

• force the removal of any php5 package
• still satisfy the php5 dependencies with some extras packages metadata

Just to be sure, did you follow the scheme provided in section 7.6.2 of https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces ? Could you please provide an example?

I'm not really sure to go this way, because forcing the php5 removal while providing a dependency compatibility could definitely break people's apps. The current solution is safer : it doesn't allow php7.0 installation while php7-untested packaged apps are still installed.

[depekavie]

I am aware, that testing each and every depending package is not within the intentions of the idea of backporting. A warning or notification should be sufficient. Currently those, who are willing to test web apps against php7 in an otherwise stable debian surrounding need to rely on manually installed packages.

Forced removal of php5(-) package(s):
Forcing the removal is not sufficient as this will break packages depending on php5.
Meta packages are, what I have tried myself, but the "Conflicts: ..:" would have to mutate into Replaces: ..." and "Provides: ..." only there, while the binary packages themselves (up to my knowledge) must not contain "Conflicts: ..." in that case.
I'd propose to make php7.0 and php7.0-{cgi|cli|fpm|common} themselves metapackages containing the keywords as expressed in section 7.6.2, while the binaries should be renamed php7.0-{cgi-bin|cli-bin|fpm-bin|common-bin}. I have to admit, that I have not yet tried that myself, yet, since I am stuck with other problems. (I manually compiled php7 from the scratch and "make test" reported some issues to the devs.)

For your concerns about breaking apps:
a) Your dotdeb.org post suggests removal of each and every php5 package before installing php7 anyways.
b) Coexistence of php5 and php7 is not intended.
c) The idea of a backport is to port a more recent version of a program back into an otherwise feature-stable distribution. It's likely, that some things will break that way.
d) Chicken-egg-problem: if users of a backport don't test existing php7-untested packaged apps, you will not know, whether they are compatible and if they need to be replaced by more recent backports themselves, don't you?

If you have other proposals, let me know if and how I can help.

[gplessis]

Thanks to Jessie's latest update, PHP 5.6 (from Debian) and PHP 7.0 (from Dotdeb) are now co-installable on the same machine. This should fix this dependency issue.