[pkg-php-pear] Composer version/dependency translation, and common autoloading scheme?
mario at include-once.org
Tue Dec 23 14:06:57 UTC 2014
Sorry in advance for the broad inquiries. Only managed to read through
half the ML archive. But still got a few basic questions.
Context: I've been building a composer-to-deb/rpm converter (based
on fpm). Mostly because I've been oblivious to dh_phpcomposer and
actually having pkg-php-tools installed already.. It might be
a neat alternative for non-DDs still:
Its output currently diverts from team-pear packages in a few ways:
* I've used `php-composer-` as package name prefix.
* And it retains the needlessly deep nested vendor/vnd/pkg/*/*/
prefixes under /usr/share/php
* Which was meant to utilize composers own autoloader stuff.
(Got a composer-rebuild wrapper working in fact.)
But now it dawned on me that this is kind of pointless.
While I wanted to eschew any conflicts with proper Debian packages,
it introduces a redundant packaging scope. Bringing it in line with
pkg-php-pear schemes shouldn't be too difficult however.
Primary question though: What kind of autoloading scheme was decided
→ Only symfony, horde-autoloader, and phpab seem to be packaged up.
Neither seems to provide a trigger for /usr/share/php.
→ Or is it really meant to be a unmanaged static file collection?
→ Library consumers must to declare a class-map themselves then?
→ (And package .regs are used for PEAR-origin packages only?)
Peeking at the current phpcomposer/source.php, it seems to implement
a super complete version/dependency translation.
→ Is this actually required by any of the existing php-vnd-packages?
Anyone got a more complex example handy :?
→ Not being familiar with all the subtleties of real deb building I
had to look up the double ~~ tilde thing. (Used for pre-sorting, ok).
But are two levels the maximum tolerated ~ tilde count for apt?
(Just wondering then why only patch/dev was grouped from a/b/rc).
→ And aren't you mostly preferring stable versions anyway?
Since I only wanted to use `fpm -s composer` for packaging a few odd
libraries, the fpm-composer plugin doesn't yet deal with complex version
relations. (Albeit fpm itself can expand ~> gem style specifiers etc.,
comparable to the ones in composer.)
I really wanted to avoid introducing any accidental dependency hell
here by transforming dependency relations too literally.
So, my long-winded question boils down to: would you recommend to
have arbitrary composer-to-deb converted packages contain similarly
detailed versions and dependency lists?
More information about the pkg-php-pear