Closed r7l closed 1 year ago
Wow! I just removed all php packages and reinstalled them - and still cannot reproduce the issue. :( But without reproduction I don't know, where this might come from. :(
Maybe some more BDEPENDS are missing... I will go through the packages once again.
(I just found out, the build to symfony-finder was broken... maybe the problem might come frome there... so as I did not mark the package as updated, you'd need to update it manually by running emerge -v1 symfony-finder
)
I guess, I will extend the build of composer to have the "test" use-flag available and will try to build the complete dev-dependency-chain to be able to run the unit-tests. But this way we will get a LOT more packages ;)
Ha! I found a possibility to reproduce the problem. It will trigger when working with "create-project". Even if not "newly" installed. So maybe there is something broken in general. :)
But now the error is observable. Und I guess it will be solvable :)
Oh, oh, oh... I'm sorry.
But the broken autoloader was me by "beautifying" the composer ebuild. I thought in the end I could use the fedora template for composer too... and overlooked, that it had a tiny difference in it.
So it has nothing todo with a new system, but me broke an already working ebuild. :(
Sorry.
Now I fixed all builds and reverted the problem I introduced in composer itself.
And from now on, I will use revision suffixes to mark changes, so that package updates will be automatically picked up.
But installing all of them freshly should lead to a working system now.
Next step would be to ajdust the autoloaders for the "bigger" components to carry their own "requires" the right way and maybe then slim down the autoload-configuration of composer.
But for now we are back to a working state. Sorry for the trouble. :/
Thanks allot for the quick fix. Composer works without issues for now.
I've noticed that it might be possible to simplify the amount of Ebuilds using the the general polyfill package instead of multiple single packages. Wouldn't that be an option? It might even be possible with some sed
lines to remove those classes for obsolete PHP version. Other then that, you're using most of what the general package offers anyways.
First of, i have to admit not to be an expert for Composer and autoloaders. I am not a PHP developer. More of devops hosting PHP applications (and other stuff). I was reading into it and what Gentoo made out of it, when working on a set of Ebuilds for Composer. Autoloaders on Gentoo (or Fedora) seem to be a bit different then what
phpab
does by default.Using
phpab
does provide a classmap but Gentoo works withPsr4
as provided incomposer.json
most of the time. The usage of classmaps seem to lead to errors when installing the Composer Ebuilds on a new system. Running any Composer command leads to this output: