[pkg-php-pear] composer and debian

[andrea rota]

hi Mathieu,

with the dependencies for php-composer being reviewed and installed on
my dev machine for tests, i'm working on php-composer itself: getting
back to earlier conversations:

On Mon, Jun 24, 2013 at 12:41:32PM +0200, Mathieu Parent wrote:
[...]
> > once composer's install task finishes, running bin/composer in the build
> > directory sources its own classes from src/ and anything else from
> > vendor/ relative to the build dir (at least, that's my understanding).
> >
> > so i'm not sure how to best 'translate' all this into the actual
> > packaging: i imagine src/, bin/ and doc/ from upstream can be easily
> > dealt with through dh_install, but i am unsure about the vendor/ folder
> > that gets created by ``php composer.phar install``: should i just *not*
> > invoke this in debian/rules (which requires a 'bootstrap' composer.phar
> > to be downloaded to a tmp dir or to be included as patch into the source
> > package) and package all the dependencies separately if not already in
> > Debian, and let dh_phpcomposer list them as dependencies in composer's
> > own debian/control?
> 
> Yes, just start with "*not*" running 'php composer.phar install' , and
> see how it goes.

'php composer.phar install' also adds into the 'vendor' folder it
creates some autoloader code, which basically makes available all the
dependencies installed in a project's 'vendor' folder available to
any code using them.

in case of system-wide installs (to start with Composer's own library
code and that of its dependencies), this autoloader code needs to be
generated in order to make the code installed under
/usr/share/php/* available.

in a way, upstream addressing their issue #55
(https://github.com/composer/composer/issues/55) should help here, but
in the meanwhile i'm reviewing the workarounds mentioned in this thread.
any further suggestions are welcome.

if/when upstream supports that, Debian packages of composer modules
should be able to dev-depend on php-composer and use it to install their
library code in the appropriate locations, i guess through an updated
dh_phpcomposer, which would be great - but it's early for this.

another question i am wondering about is naming of packages: pkg-php-tools
correctly uses the whole composer package name to infer a debian package
name - e.g. seld/jsonlint translates to php-seld-jsonlint. this helps to
differentiate upstram forks, but i'm wondering, in the longer term, how
to deal with changes of name upstream (e.g. if the 'org' or 'user' part
of a org/project or user/project composer package name is changed in
packagist, or if the reference implementation becomes one from a
different org); moreover, it's probably unusual to have user or org
names in debian packages: i guess there isn't much that can be done
about this, but wanted to highlight this side of the composer naming
game.

(so i should probably rename the two other composer dependency packages
i'm working on to php-seld-jsonlint, from php-jsonlint, and
php-justinrainbow-json-schema, from php-json-schema).

and finally - pkg-php-tools should probably enforce dependency on
php5-cli *only* (rather than php5 | php5-cli) via substvars when there
is a 'bin' section in a project's composer.json (this is to avoid
lintian error php-script-but-no-phpX-cli-dep). if i'm not missing
something here, i can report a bug for this against pkg-php-tools.

best,
andrea

-- 
andrea rota

Xelera - IT infrastructures
http://xelera.eu/contact-us/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1530 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-php-pear/attachments/20130628/e3e77b2b/attachment.sig>