Le 18/04/2016 10:47, James Hogarth a écrit : > For application builds were versions matter should we perhaps think about > dropping the php-composer() based requires? > > Just go by the actual names of the packages instead that we maintainers > have tested against and know our applications work for? Yes, this is a possible way (for Requires) For BR, in fact this is not a real issue - both versions are installed - ensure there is no conflict - ensure the app use the right version > Or perhaps we should extend the virtual provides of php-composer to > something like php-composer(symfony/events/28) or something similar to this? > > Symfony immediately comes to mind due to the conflict between drupal > requiring < 2.8 and the current owncloud release requiring > 2.8 which is > preventing the rawhide/f24 builds of it at the moment, and would be a > conflict in EPEL7 potentially too with the different lifecycles of > applications concerned. Or simply setting only the max version. yum/dnf should select the "best" version under the limit. This "multiple versions" feature is really a big one ;) Remi. > > > > On 18 April 2016 at 08:29, Remi Collet <Fedora@xxxxxxxxxxxxxxxxx> wrote: > >> Another fun... >> >> BuildRequires: php-composer(nikic/php-parser) >= 1.4 >> BuildRequires: php-composer(nikic/php-parser) < 2 >> >> >> => both versions are installed... >> >> >> Remi. >> _______________________________________________ >> php-devel mailing list >> php-devel@xxxxxxxxxxxxxxxxxxxxxxx >> >> http://lists.fedoraproject.org/admin/lists/php-devel@xxxxxxxxxxxxxxxxxxxxxxx >> > > > > _______________________________________________ > php-devel mailing list > php-devel@xxxxxxxxxxxxxxxxxxxxxxx > http://lists.fedoraproject.org/admin/lists/php-devel@xxxxxxxxxxxxxxxxxxxxxxx > _______________________________________________ php-devel mailing list php-devel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/php-devel@xxxxxxxxxxxxxxxxxxxxxxx
