[pkg-php-pear] Composer version/dependency translation, and common autoloading scheme?

[mario]

Hi everyone,

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:

http://fossil.include-once.org/xpm/wiki/source_composer

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
on meanwhile?
→ 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?

Thanks,
mario