As to the ebuild, dev-php/composer depends on RDEPEND=" ... >=dev-php/ca-bundle-1.0.0 >=dev-php/cli-prompt-1.0.0 >=dev-php/psr-log-1.0.2 dev-php/fedora-autoloader >=dev-php/json-schema-2.0.0 >=dev-php/jsonlint-1.4.0 >=dev-php/phar-utils-1.0.0 >=dev-php/semver-1.0.0 >=dev-php/spdx-licenses-1.0.0 >=dev-php/symfony-console-2.7.9 >=dev-php/symfony-filesystem-2.7.20 >=dev-php/symfony-finder-2.7.20 >=dev-php/symfony-process-2.8.12" I am not 100% sure, but I think composer does not necessarily depend on all of this! See https://getcomposer.org/download/ There are almost no requirements for composer. I think most of the packages above are optional. Maybe you could provide some use flag?
The package from getcomposer.org contains all of these as they are bundled. In gentoo, the deps are unbundled and so you see all of these. Check https://github.com/composer/composer/blob/master/composer.json.
Have a look at https://getcomposer.org/download/ php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');" ... php composer-setup.php php -r "unlink('composer-setup.php');" It just produces one .phar file?!
And have you checked what is included in the phar file? :)
Hey Manuel and Tomáš, so yes composer has a lot of dependencies, anyone can check them at: https://packagist.org/packages/composer/composer Beside that, I try to not include anything not necessary in the package, but if you find any useless dependencies we'll check again, but as this as been done (and it take a lot of time) I think, we'll stick to the packagist manifest, but I may be wrong. Some related reading here: https://bugs.gentoo.org/439206 I try to add the tests suite in the package but this require a lot of patching and new packages to add, but other than that, I am not sure of the useful flags we could have, but again feel free to share your ideas. Guillaume.
What about a use flag that does * if not set does provide the current behaviour * if set, the ebuild generates one monolithe composer(phar) file by using the "offical" downloading code. This could improve setup speed and reduce Gentoo-dependencies.
Actually "bin" packages (or pre-built) packages are usually just a last resort in Gentoo. Given we have a proper package, I don't think it's going to happen. Why are the deps problematical? They are small and seldom change... If you want, you can keep such a trivial "bin" package in your overlay, something like: http://data.gpo.zugaina.org/awesome/dev-php/composer/composer-1.1.2.ebuild
Thank you. We will add an ebuild to our own portage overlay. To your question regarding dependencies: We are trying to keep package list and compile time minimal, even when having a build server. The list of package dependencies is not long, but maybe to much for having it in a production server serving websites.
If you use upstream's phar, then you still have all of those dependencies on your system, but your package manager won't know about them. So they still get loaded, still take up disk space, etc., but, * The phar never receives security updates. * If other packages need those same dependencies, you wind up with two (or more) copies of them. Essentially, you're on your own for updating everything in the phar file except composer itself. The whole point of the package manager is to save you that headache =)
