https://bugzilla.redhat.com/show_bug.cgi?id=1021749 --- Comment #7 from Remi Collet <fedora@xxxxxxxxxxxxxxxxx> --- Thanks for pointing the exact problem: "this is not designed to be packaged". Sorry, but you know my feeling about composer (bull-shit-to-create-broken-system), so I will try to not be too rude in my answer ;) Most components are distributed via a pear channel, to be installed system-wide, and be used by other app. And it works, p.e: PHPUnit uses various Symfony2 component (and I haven't try yet how PHPUnit will react with symfony2 from outside pear channel, thus, with lot of pear broken dep). For other things, (probably those which are not available in pear channel), this seems to means they are not designed for such usage (and honestly, afaik, upstream really don't care). So if we are unable to provide a simple autoload mechanism for them, (and so, to run test unit), this mean that nobody will be able to use them, and so, that packaging have absolutely no sense. If we package a framework, this is to be able to use it from a packaged web application (other people will very probably not even try to use it). Ex : ZF2 is used by GLPI, and all works as expected, without any hack. So for your proposal (2) sorry again, but I can't even imagine how this can be usable. "composer install" will pull all the needed dependencies, and install them in "vendor", exactly what we don't want (bundled-lib-factory) and what will happen is someone run "composer install" in this dir ? So, yes (1) still for me the only way to go. Please prove me that packaging this way (single spec vs per pear component spec) is really possible and have some sense. -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review