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.
_______________________________________________
php-devel mailing list
php-devel@xxxxxxxxxxxxxxxxxxxxxxx
http://lists.fedoraproject.org/admin/lists/php-devel@xxxxxxxxxxxxxxxxxxxxxxx
