[pkg-kolab] Bug#821686: Bug#821686: Bug#821686: src:libkolab: PHP 7.0 Transition

Fri Apr 29 12:51:21 UTC 2016

Control: severity -1 serious
Control: block -1 by 821687

Hi Ondřej,

also libkolab is using swig and it is blocked by libkolabxml. So setting 
severity to serious, so the swig related packages doesn't block PHP 7.0 
transition.

In both packages, all php code is translated via swig.

what is the correct way to create php modules nowadays?

debian/rules:
PHPAPI := $(shell php-config --phpapi)
[...]
override_dh_gencontrol:
        echo "php:Depends=phpapi-${PHPAPI}" >> debian/php-kolab.substvars
        dh_gencontrol
[...]

debian/php-kolab.install:
    usr/lib/php5/*/kolabcalendaring.php usr/share/php/
    usr/lib/php5/*/kolabicalendar.php usr/share/php/
    usr/lib/php5/*/kolabobject.php usr/share/php/
    usr/lib/php5/*/kolabshared.php usr/share/php/

I can image that, we should not move the modules to /usr/share/php/ anymore, 
to have a clear versionbased path?

Regards,

--
Am Freitag, 29. April 2016, 13:57:02 CEST schrieb Sandro Knauß:
> Control: block -1 821687
> 
> Before adding php7 support to libkolab, we need to fix libkolabxml.
> --
> 
> Am Montag, 18. April 2016, 23:02:28 CEST schrieb Ondřej Surý:
> > Package: src:libkolab
> > Severity: important
> > User: pkg-php-maint at lists.alioth.debian.org
> > Usertags: php7.0-transition
> > 
> > Dear maintainer(s),
> > 
> > this bug is a part of ongoing php7.0 transition.  It is filled as
> > important, but the severity will be bumped to serious within quite short
> > (~month) timeframe as the transition was announced almost 3 months ago.
> > 
> > The libkolab package currently build-depends on php5 php5-cli php5-dev .
> > 
> > PHP 7.0 has landed in unstable with substantial changes to the packaging:
> >   1. Every package built from src:phpMAJOR.MINOR now include
> >   
> >      phpMAJOR.MINOR in the name, so f.e. php5-fpm is now php7.0-fpm.
> >   
> >   2. Accompanying src:php-defaults builds 1:1 mapping to a default
> >   
> >      MAJOR.MINOR version, e.g. php-fpm depends on php7.0-fpm.  When you
> >      specify a dependency, please use the generic name, unless you
> >      absolutely know that won't work for you.
> >   
> >   3. Every path in the system has been changed to a versioned, e.g.
> >   
> >      /etc/php5/cli is now /etc/php/7.0/cli
> >   
> >   4. dh_php5 is now dh_php
> >   
> >   5. php-pear is not built from independent source package.
> >   
> >   6. master-7.0 branches of several extensions (php-apcu, xdebug,
> >   
> >      php-apcu-bc) can be used as a template how to change the PHP
> >      extension packaging.  It's mostly cut&paste since the d/rules tries
> >      to figure-out most of the variables from debian/ directory.
> >   
> >   7. pkg-php-tools package now supports PHP 7.0 packaging and if your
> >   
> >      package uses pkg-php-tools a simple binNMU is all it might need
> >   
> >   8. PHP 7.0 has changed extension API, so most-if-not-all extensions
> >   
> >      need work from upstream to be compatible with PHP 7.0.
> >   
> >   9. We expect to ship next Debian release (stretch) only with PHP
> >   
> >      7.0, that means that all packages needs to be made compatible with
> >      PHP 7.0.  Fortunately the PHP 7.0 is mostly compatible with properly
> >      maintained software.  However some extensions has been deprecated
> >      (f.e. mysql) and thus old unmaintained software will stop working
> >      and it will have to be either patched or removed from stable Debian.
> > 
> > So what you need to do:
> > 
> > Replace every occurence of php5 with just php, e.g. if you depend on
> > 'php5' then you just need to depend on 'php'.  Also if you package a web
> > application and depend on specific SAPI, I would recommend depending just
> > on 'php' package and let the user decide whether he will install php-fpm,
> > libapache2-mod-php or php-cgi.
> > 
> > The script that was used to get the list of packages for MBF was not a
> > particular smart one (so it doesn't detect alternatives, etc.), so if
> > there's a false positive, please excuse me and just close the bug with
> > short explanation.
> > 
> > The other options that might be used with packages that don't and won't
> > support PHP 7.0 is to remove the software from Debian by changing the
> > 
> > title of this bugreport to:
> >     RM: libkolab -- ROM; doesn't support PHP 7.0
> > 
> > reassigning it to ftp.debian.org pseudo-package and changing severity to
> > 'normal'.
> > 
> > Also feel free to contact the maintainers at one of the lists:
> > 
> > pkg-php-pear at lists.alioth.debian.org -- for PEAR related packages
> > pkg-php-pecl at lists.alioth.debian.org -- for PHP extensions
> > pkg-php-maint at lists.alioth.debian.org -- main PHP packaging and catch-all
> > 
> > Cheers, Ondrej
> > 
> > -- System Information:
> > Debian Release: 8.4
> > 
> >   APT prefers stable-updates
> >   APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500,
> > 
> > 'stable') Architecture: amd64 (x86_64)
> > 
> > Kernel: Linux 4.2.0-35-generic (SMP w/24 CPU cores)
> > Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8)
> > Shell: /bin/sh linked to /bin/dash
> > Init: systemd (via /run/systemd/system)
> > 
> > 
> > _______________________________________________
> > pkg-kolab-devel mailing list
> > pkg-kolab-devel at lists.alioth.debian.org
> > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kolab-devel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.alioth.debian.org/pipermail/pkg-kolab-devel/attachments/20160429/45954dbe/attachment-0003.sig>