On Thu, Jun 27, 2013 at 07:51:01PM -0400, David Prévot wrote: [...] > Then, some nitpicking details: > > Framework should be framework in Description from debian/control.
thanks, this is fixed now.
> The email address of the upstream copyright holder should appear in
> debian/copyright.
ok, fixed.
> Please, consider renaming debian/php-symfony-process.docs and
> debian/php-symfony-process.install into debian/docs and debian/install
> (that will ease the comparison/copy between php-symfony- packages as
> long as they produce only one binary package).
very good point - fixed.
[...]
On Fri, Jun 28, 2013 at 10:14:31AM +0800, Thomas Goirand wrote:
[...]
> IMO, the long description should have:
>
> Symfony is a PHP framework, a set of tools and a development
> methodology.
>
> *after*
>
> This package provides the Process component, which executes commands in
> sub-processes.
>
> Because describing the Symfony framework should (IMO) appear in all
> description of all Symfony packages, and it may be better to read this
> way for anyone using the package. Also the paragraph which doesn't
> describe the Symfony framework should be, IMO, longer. The only words
> that are helpful are "which executes commands in sub-processes" (the
> rest is in the package name itself). Please extend this long description.
agreed - longdesc is updated. i personally find it easier to read the
generic Symfony framework description first and the component's
description second, but either way works well so i have updated control
according to your suggestion.
> Last, and that's the most important bit that *must* be fixed before
> upload, the resulting package doesn't depend on pear-symfony-channel. I
> don't think it is right to put: ${phpcomposer:Debian-require}. I am
> guessing it is because ${phppear:Debian-Depends},
> ${phppear:Debian-Recommends} and ${phppear:Debian-Breaks} are missing.
> It would also be a good idea to use ${phppear:summary} and
> ${phppear:description} if they produce a correct output (I didn't check
> if they do, sometimes we don't use them if they don't).
having followed this part of the thread between yourself and Mathieu, i
have left the phpcomposer substvars in place and have *not* added any
phppear ones.
Mathieu, you mentioned that the Symfony PEAR channel is out of date -
however, as Thomas pointed out, somehow confusingly there are two
distinct ones at different domains, and http://pear.symfony.com/ seems
indeed indeed up to date to me, with all components up to version 2.3.1.
however, to add to the confusion, upstream's PEAR packages use symfony2
as part of the package name, whereas upstream's composer.json data use
symfony. unless i'm missing something, Debian packages for these
Symfony(2) components could be generated either via phpcomposer or
phppear, although this needs to be done consistently (which is easy
since we're just starting and there aren't that many components).
i assume upstream provide both distribution methods for different use
cases (PEAR for system-wide installs, composer for in-project-folder
installs).
other than this, i think php-symfony-process should be in rather good
shape by now:
http://anonscm.debian.org/gitweb/?p=pkg-php/php-symfony-process.git;a=summary
best,
andrea
--
andrea rota
Xelera - IT infrastructures
http://xelera.eu/contact-us/
signature.asc
Description: Digital signature
