[pkg-php-pear] Let's reconsider the way Symfony2 Components are packaged for Debian

David Prévot david at tilapin.org
Mon Sep 8 14:04:38 UTC 2014


Le 08/09/2014 02:35, Daniel Beyer a écrit :
> On Sun, 2014-09-07 at 16:27 -0400, David Prévot wrote:
>> Le 07/09/2014 15:28, Daniel Beyer a écrit :

>> - you may wish to regroup paragraphs about the same license.
> Done, by respecting depths and wildcards. You can check that with:
> # grep -E "^(License|Files):" debian/copyright

I actually meant “factorize”. E.g.:

Files: …/WebProfilerBundle/Resources/views/Profiler/body.css.twig
Copyright: 2010, Yahoo! Inc.
License: BSD-3-clause-yui

Files: …/WebProfilerBundle/Resources/views/Profiler/profiler.css.twig
Copyright: 2008, Yahoo! Inc.
License: BSD-3-clause-yui

Could simply be:

Files: …/WebProfilerBundle/Resources/views/Profiler/body.css.twig
Copyright: 2008, 2010, Yahoo! Inc.
License: BSD-3-clause-yui

(but grouping as you did is a good first step in that regard).

>>> - No tests are run, mainly due to two missing build-dependencies [1]. I
>>> vote taking care about enabling tests during build after the package
>>> made it into Debian.
>> Please, just deactivate the tests you can’t run instead.
> The other reason is, that currently there is no support in d/rules to
> run any test at all. I'll check how this can be done, since in fact most
> of the tests should already run. I think I can work on this Wednesday.

Many PEAR (and Composer) packages run their tests suite at build time
and at run time (via DEP-8), they can be spotted on the DDPO page (look
for those with “pass” in th CI column) if you want some examples.


>> I’ll upload php-doctrine-data-fixtures ASAP (it’s already almost ready),

I already fixed one upstream issue, but there is another one that bites
me (hopefully, that shouldn’t take too long).

> One more thing came up my mind while I grouped the licenses:
> I'm not sure if it's right what I've done with
> src/Symfony/Component/CssSelector/* in d/copyright. If it really is a
> port of the Python cssselector library (as pointed out by Symfony's
> upstream), than it should be "Expat and BSD-3-clause-cssselector"

As you properly did it for the other ports, I believe the “A and B“
would be more accurate (more consistent at least).

> even if Symfony's upstream does not include this license anywhere in its
> code/documentation (as it would be required by the BSD 3-clause).

That’s just an upstream bug, no need to reproduce it then ;).

About ports from one language to another, one often mention the source
of the initial work merely as a polite reference, but you’re right that
it should stay in the copyright, thanks for your careful review (and you
thus may report the issue upstream).

FWIW, I reviewed Component/[B-I] yesterday, and hope to do more today
(and if someone else intends to looks into Bridge or Bundle today,
please, say so).

Some remarks (in no particular order) that crossed my mind while
reviewing (some may be stupid: I haven’t yet rebuild or looked closely
at the package, apologies if they are):
- are you sure the “Test” (without final “s”) directories should be
  stripped away?
- you may exclude (with -X) at dh_install time instead of deleting at
  override_dh_auto_build time;
- some README.md are useless and thus shouldn’t be shipped in the
  package (e.g., src/Symfony/Component/PropertyAccess/README.md); maybe
  the file size reflects its usefulness;
- some package provides executables, maybe they should be moved in the
  PATH if they are useful (with extra care to keep them working), or
  not shipped at all if they aren’t (see Component/Intl/Resources/bin/);
- if a binary package doesn’t provides it’s own changelog, maybe the
  generic one could be used as a replacement;
- I kinda liked the idea of a meta symfony package, what changed your
  mind about it? (Thinking about doctrine and zendframework, I think it
  will be nice to keep those (empty) packages once split too, but maybe
  am I seeing it wrong);
- you may wish to call mkdir with -p (in order to remove the earlier
  mkdir, and thus save a few lines in d/rules that is already big: it
  may make it more readable, or at least less frightening ;-).



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-php-pear/attachments/20140908/0c8afde2/attachment.sig>

More information about the pkg-php-pear mailing list