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

[David Prévot]

Hi Daniel,

Le 21/09/2014 18:09, David Prévot a écrit :
> Le 21/09/2014 14:14, Daniel Beyer a écrit :
> 
>>(Don’t get tricked by
> the actual object of this message, I’ve not yet started to review your
> latests changes to the packaging).

Now I’m done, and I don’t have much to add. Let me focus on the
important points (advices and other non blocking suggestions from the
previous message stripped away).

>> On Mon, 2014-09-08 at 10:04 -0400, David Prévot wrote:
>>> 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 :

>> It inspired me to reduce complexity of d/rules even more - see commit
>> 6faab753dc0dba49d3a110c275b949a2b5118b30 for details:
> 
> I overlooked it earlier today, and believe it’s a good move, thanks for
> that!

I’d like to have something clever to suggest in order to not need to
write all these debian/packages_to_build/$deb_pkg_name files (and not
replace them by some hard-coded pain to maintain stuff, but they are
minimalist and are thus nice. Maybe (with a capital “M”) having a
“prepare” (or whatever the name) target, not run at build time, that
would write the needed $deb_pkg_name.install and $deb_pkg_name.docs file
would be nicer (but no idea yet how to deal with dh_phpcomposer and
dh_installchangelogs, so that’s just an idea in the wind now).

The build looks and runs fine, that’s the more important thing anyway,
thanks, it’s not the usual trivial PEAR or Composer package you’re
dealing with!

>>> - some package provides executables, maybe they should be […]
>>>   not shipped at all if they aren’t (see Component/Intl/Resources/bin/);
>>
>> I took a look at them and came to the result that they all are not
>> useful during runtime at all.

> Maybe will it be simpler to handle the removal with the -X switch

Just did that: “-XResources/bin” is a lot more simple than a patch, and
the patch didn’t delete the empty directories anyway.

I made a few other minor changes (trying to be efficient instead of
asking you to do it, at the cost of some time in the process), they were
just nitpicking.

>> I think it now is not too frightening anymore. :-)
> 
> I’ll try and review it more precisely within a few days

Scratch the final “s”.

> Another thing on the top of my head: in
> 5b6fa15f (Update versioned Replaces: and Breaks: fields in d/control)
> the version (“Breaks: php-symfony-classloader (<<2.3.19~)”) won’t work
> if we actually upload a 2.3.19-1~sid1 version, maybe you wish to use
> “2.3.19-1~t” instead, since dpkg will understand the following if I’m
> not mistaken.
> 	2.3.19~ < 2.3.19-1~sid1 < 2.3.19-1~t < 2.3.19-1

Second thought, 2.3.19-1 should be fine (and shorter and more explicit
than 2.3.19-1~t), since symfony has a higher version anyway (2.3.19+dfsg…).

That makes me think I may use (except for the php-symfony-console
standalone package that should be versionned 2.3.19+dfsg-1~sid1 anyway),
a simple 2.3.19-1 version for all the standalone package I’m preparing
(but don’t mind keeping 2.3.19-1~sid1 for php-symfony-classloader and
php-symfony-eventdispacher if you’re actually expecting such version to
deal with the transition, but see the following paragraph). If so, using
“<< 2.3.19-99” should be on the safe side ;).

As for the php-symfony-yaml, maybe a versionless transition could be
considered too (and easier). We should run test upgrade to be sure
anyway (I encourage you to do some test upgrade on your own, I’ll do
some too on my own before uploading). (I have some doubts about the
compatibility of a versionless transition with a transitional dummy
package anyway…)

About override_dh_auto_test, it shouldn’t run if nocheck is set in
DEB_BUILD_OPTIONS, see other packages that run tests.

You may wish to document the copyright information in your scripts
(debian/licensing/bin/*), the Expat license is short anyway, so it
shouldn’t be troublesome (and may help to see your script being adopted
elsewhere, or even generalized, thanks for them by the way!).

Regards

David

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