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

David Prévot taffit at debian.org
Wed Jul 3 17:00:28 UTC 2013

Hash: SHA256

Le 03/07/2013 12:26, andrea rota a écrit :
> On Wed, Jul 03, 2013 at 10:24:21AM -0400, David Prévot wrote:

>> Lintian pointed me a prebuilt binary for Microsoft Windows, is it
>> DFSG-compliant?

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

echo alias lintian='lintian -EI --pedantic' >> ~/.bash_aliases

should do ;-).

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

Right, another option would have been to add the sources, and ensure one
can build it with Debian tools, but I doubt it would worth the effort…

> if you agree, i can drop this - i guess it's best to git rm it from the
> debian-sid tree

Please, drop it from the upstream branch (or make an intermediary
dfsg-branch) with the actual upstream (from Debian PoV) branch.

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

You could also repack the tarball directly on download as we do in,
e.g., owncloud or spip (and if the repack fails because the filepath
changed, one has to fix it, so it lowers the risk of including the
non-DFSG material back by mistake):


(and the watch file does the trick so the get-orig-source rules’ target
still works):


A pristine-tar branch would be nice to have, especially when using
repacked material.

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

Not mandatory, but nice to have to make it clear the upstream tarball is
not use. No X needed.

>>>> P.-S.: would be nice if we could package all those PEAR binaries from
>>>> the same already existing source…

> In the meanwhile upstream seem to be using their git repo to generate
> the PEAR channel packages so things should be ok,

I haven’t tried to figure out how they generate the PEAR packages and
according package.xml file, but if that were possible, it could be a
nice starting point to package them all from the same source
(pkg-php-tool will probably need some tweaks to handle multiple binaries
too, but that would be a nice enhancement).



Version: GnuPG v1.4.12 (GNU/Linux)


More information about the pkg-php-pear mailing list