[pkg-php-pear] Symfony package review (was: Let's reconsider the way Symfony2 Components are packaged for Debian)

Daniel Beyer dabe at deb.ymc.ch
Tue Sep 23 17:52:14 UTC 2014

Hi David,

Am Sonntag, den 21.09.2014, 18:09 -0400 schrieb David Prévot:
> Hi Daniel,
> (...)
> The licensing is very clear IMHO, thanks for your work on it and the
> detailed comments. I believe it’s OK to keep this level of details as
> you did, especially before an actual review by our ftpmasters. I just
> want to point out that it can be shorten:
> (...example...)
> as allowed by the current format specification. We don’t need to comment
> about the reason of the copyright/license anyway. I used to keep this
> initial level of detail myself, but the copyright file can be huge in
> some cases (yes, owncloud, I’m looking at you), and thus took advantage
> of the shorter form to make it easier to read (at the cost of being a
> bit more tricky to update when files are deleted, or added…).
> In short: I believe the form you chose is fine, and there is no need to
> remove all the explanations currently present, but you may consider
> using a shorter form in the future, if it suits you better.

That's good to know. I definitely keep this in mind for future. Not
removing them for now, since they might be of some use for ftpmasters
during their initial review.

> Haven’t yet looked into how you managed to make the Test(s) directory
> available in the PHP path while testing the actually installed content
> of the packages for the DEP-8 tests, I hope you found something nicer
> that the hacks I pushed into the standalone php-symfony-console or
> php-symfony-process for example, but that will be for another day (I’m
> fed up with looking into the Symfony code for today ;-).

No, sorry. It basically is the same approach. I think we should more
generally think about how to substitute the autoloading job composer
does in Debian.
Maybe Mathieu already as an idea since I remember him mentioning
something like this in the depth of this thread (see "Milestone 2" in
his mail from May 24th):

> >> - 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;
> > 
> > You're right. Since I did not want to blow up d/rules again, I simply
> > patched those out of upstreams code for now.
> Glad to see your comment (especially the “for now” part): as for the
> copyright part, I think your approach is overly careful (e.g., I
> personally wouldn’t have bothered to strip away the PHPUnit
> documentation out of the upstream README, but agree that’s a clever
> thing to do). The patch thing may be a pain to maintain in the long
> term, but that can be dealt later (no need to implement an easier
> solution right now, since an extensive and accurate job has been done).
> Disclaimer: I’ve not yet looked into the specifics of your changes, just
> commenting after my initial overlook.

I have this on my list and plan to add README.Debian files some time in
future (e.g. mentioning tests can not be run as described in upstream's
README and explaining why and maybe a hint about autoloading).
I start not later, than the patch file on this becoming a pain... :-)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/pkg-php-pear/attachments/20140923/0d63ec79/attachment.sig>

More information about the pkg-php-pear mailing list