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

[Daniel Beyer]

Hi David,

Am Montag, den 22.09.2014, 14:49 -0400 schrieb 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).
> 

Okay, thanks. I therefore delay any potential work on those from the
previous message (most likely I schedule them even behind a first upload
of the package).


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

I was thinking about this, since I read your mail yesterday. So far
nothing came up my mind, how to change d/rules in a consistent and
improving way. I don't want to do a rush job here and would prefer to
let it settle down for now. I have it on my list and I'm sure either of
us (or on the list) will come up with a brilliant idea how to improve
this.

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

I agree: The binary packages look good.
Thus and if that's okay for you, I would prefer if we could leave
d/rules the way it is for now and care about it without the
jessie-freeze breathing down our necks.


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

Thanks, that really looks much nicer. I kind of was in a patch-tunnel
the last few days, so this much easier to handle solution not really
came up my mind... :-)


> 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 saw them, they all look fine - thanks.


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

Yeah. And thanks a lot for this promptness.


> > 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 ;).
>
<{You already added: 'using "<< 2.3.19+dfsg" will be fine.'}

I like the 2.3.19-1 versions more. But the versions in Replace: and
Breaks: needs to be increased to something like '2.3.19+dfsg~' or (as I
understood) they will not work. I'm not sure what will happen with no
'<<VERSION' at all, but I'll try that out...


> 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…)
> 

A few days ago, when I added DEP-8 tests, I ran into a pretty bad
situation: apt complained about (the new) php-symfony-yaml and
php-symfony2-yaml sharing same files and that's why I added the
"Conflicts: php-symfony2-yaml" in src:symfony for php-symfony-yaml.
Reason for both being installed was phpunit depending on
php-symfony2-yaml and I manually installed php-symfony-yaml from
src:symfony. I played around a bit with Replaces: and Provides: fields
with the goal to have phpunit and php-symfony-yaml installed the same
time. Finally I gave up and simply rebuild phpunit to no longer depend
on php-symfony2-yaml, since I was eager to finish the DEP-8 part.

I think now it's time to dig into this and do, as you suggested, some
test upgrades. I'll let you know as soon as I have findings.


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

Done.

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

... and done. Thanks for the suggestions.

Greetings
Daniel
-------------- 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/6921b759/attachment.sig>