Howdy,
The current PHP Packaging Guidelines recommend to install each library (when possible) in a PSR-0 compliant tree.
This was a nice idea. But this doesn't work for multiple versions.
Some packages are coming soon which allow multiple versions to be installed.
- php-guzzlehttp-guzzle (v5.3) php-guzzlehttp-guzzle6 (v6.2)
- php-aws-sdk (v2.8) php-aws-sdk3 (v3, review #1264654)
- php-PHPParser (v1.6) php-nikic-php-parser (v2.0, review #1327566)
- phpJsonSchema (v1.4) php-justinrainbow-json-schema (v2.0, review #1327511)
and probably more soon...
For consumer, this is easy, as far as the provided autoloader is used.
In such case, we have to use a PSR-4 instead of the standard PSR-0 one.
@shawn: this is going to be a blocker if we need such versions in EPEL-6, IIRC you have proposed to backport this class, seems a good idea now ;)
About weak dependencies
Ex (from php-Silex, old version)
Suggests: php-composer(monolog/monolog) Conflicts: php-composer(monolog/monolog) < %{monolog_min_ver} Conflicts: php-composer(monolog/monolog) >= %{monolog_max_ver}
This of course doesn't work if we have 2 providers which can be installed simultaneously.
So the first idea was to use the real package name
Suggests: php-composer(monolog/monolog) Conflicts: php-Monolog < %{monolog_min_ver} Conflicts: php-Monolog >= %{monolog_max_ver}
After some more thinking I think the conflicts are probably unneeded.
If Monolog breaks its API, according to semver, upstream will bump the major version to 2, and so we are going to package it as php-monolog2, and the autoloader will be elsewhere, so not used.
Again, great thanks to Shawn for his work and sharing his thoughts on these changes.
Perhaps some other better ideas ?
Remi.
Another fun...
BuildRequires: php-composer(nikic/php-parser) >= 1.4 BuildRequires: php-composer(nikic/php-parser) < 2
=> both versions are installed...
Remi.
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?
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.
On 18 April 2016 at 08:29, Remi Collet Fedora@famillecollet.com 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@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/php-devel@lists.fedoraproject.org
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@famillecollet.com 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@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/php-devel@lists.fedoraproject.org
php-devel mailing list php-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/php-devel@lists.fedoraproject.org
On Mon, Apr 18, 2016 at 4:47 AM, James Hogarth james.hogarth@gmail.com wrote:
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?
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.
Don't worry about Drupal 8 any more. Drupal 8.1 switches over to Symfony 2.8 and the drupal8 package is still in review request anyway -- https://bugzilla.redhat.com/show_bug.cgi?id=1302909 . I will be updating that pkg to 8.1 "soon".
FYI: That package has an "interesting" autoloader because the app needed the Composer autoloader object so the RPM needed to modify the composer.json file and run "composer dump-autoload" during %build. Check out the spec file at https://github.com/siwinski/rpms/blob/master/drupal8/drupal8.spec if you're interested.
On 18 April 2016 at 08:29, Remi Collet Fedora@famillecollet.com 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@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/php-devel@lists.fedoraproject.org
php-devel mailing list php-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/php-devel@lists.fedoraproject.org
php-devel@lists.fedoraproject.org