[pkg-php-pear] RFS - php-symfony-console and php-symfony-finder

[andrea rota]

On Wed, Jul 03, 2013 at 10:24:21AM -0400, David Prévot wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> Le 03/07/2013 05:29, andrea rota a écrit :
> > On Tue, Jul 02, 2013 at 07:24:53PM -0400, David Prévot wrote:
> 
> > php-symfony-console and php-symfony-finder are now updated with the
> > changes you had suggested for the -process package:
> 
> The upstream README doesn’t seem installed, is this intentional?

no, sorry - the debian/docs had slipped out of my reusing of the earlier
php-symfony-process debian folder. i have pushed commit 8e08bf5 which
fixes this.

> Lintian pointed me a prebuilt binary for Microsoft Windows, is it
> DFSG-compliant?
> 
> Console-2.3.1/Symfony/Component/Console/Resources/bin/hiddeninput.exe

uhm, i think i need to set stricter options for lintian - this was not
detected and i didn't notice it :S

according to Console-2.3.1/Symfony/Component/Console/README.md, this
comes from https://github.com/Seldaek/hidden-input, where it states that
this is in the public domain.
however, since this is only used under Windows anyways:

 if (defined('PHP_WINDOWS_VERSION_BUILD')) {
   $exe = __DIR__.'/../Resources/bin/hiddeninput.exe';

   // handle code running from a phar
   if ('phar:' === substr(__FILE__, 0, 5)) {
     $tmpExe = sys_get_temp_dir().'/hiddeninput.exe';
     copy($exe, $tmpExe);
     $exe = $tmpExe;
   } 

(from Console-2.3.1/Symfony/Component/Console/Helper/DialogHelper.php),
i'd say it should be best to just drop it, since even if it is in the
public domain, the source is not included and would need to be added
from its upstream, plus i'm not sure about the binary being packaged
anyways.

if you agree, i can drop this - i guess it's best to git rm it from the
debian-sid tree (and perhaps add it to .gitignore to make sure it
doesn't come back by mistake on updates of code from upstream - unless
they change path, but then it'll be detected by lintian) so that it
isn't included in the source tree at all, or is there a specific policy
on how to deal with these cases?

in either case, would this require versioning the package as
2.3.1+dfsgX once the binary is removed?

> I just fixed the get-orig-source target in php-symfony-eventdispatcher,
> you may wish to do the same in your php-symfony-* packages.
> 
> http://anonscm.debian.org/gitweb/?p=pkg-php/php-symfony-eventdispatcher.git;a=commitdiff;h=f46a0d93afc77a1323dbd6e0454877420ed40612

thanks, i have updated debian/rules accordingly across the symfony
packages i'm working on.

> >> P.-S.: would be nice if we could package all those PEAR binaries from
> >> the same already existing source…
> > 
> > do you mean generating most of the files in debian/ from shared
> > templates?
> 
> No, I meant handling only one source package to generate all binaries.
> 
> 	https://github.com/symfony/symfony

got you - makes sense: we would get all of the components with little
extra initial effort.

> Please note that the PEAR install is tagged as obsolete on their
> website, in favor of the Composer one, so we may have to come back to
> the initial idea of packaging via dh_phpcomposer one day.
> 
> 	http://symfony.com/components

yup, although it may take a while to get Composer in good shape for
release and to be depended upon for builds etc.
In the meanwhile upstream seem to be using their git repo to generate
the PEAR channel packages so things should be ok, but we need to keep an
eye on this - even just to assess that any security updates make it
equally swiftly to their PEAR channel.

thanks
andrea

-- 
andrea rota

Xelera - IT infrastructures
http://xelera.eu/contact-us/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1530 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-php-pear/attachments/20130703/f7a46aa5/attachment.sig>