Hi,
See : https://github.com/sebastianbergmann/phpunit/wiki/Release-Announcement-for-P...
This means that the PEAR channel is going to be deprecated.
So I(m going to start to move the dependencies from pear channel to github sources.
Already done for php-phpunit-Version https://github.com/remicollet/remirepo/commit/44d4e911d5abf05dbee29e65b70d58...
I have run some tests, phploc and phpcpd still work with this new package layout.
Probably we need some Guildelines to facilitate such migration.
My idea is:
- pear package MUST (names from package.xml) Provides: php-pear(foo) = %{version} Requires: php-pear(bar) >= x.y
- composer packages MUST (names from composer.json) Provides: php-composer(foo) = %{version} Provides: php-composer(foo) >= %x.z
- composer packages SHOULD temporary provides Provides: php-pear(foo) = %{version}
- composer packages MUST not Requires: php-pear(bar) >= x.y
This allow us to track (using repoquery) pear dependencies, and this temporary provides could be dropped when no more required.
Of course this have to happen mostly in rawhide.
Feedback ?
Remi.
P.S. as PHPUnit 3.7 is a LTS version, I plan to keep it for some time in Fedora <= 20 and EPEL <= 6.
Hi,
Good idea. Is there a page for that in the Wiki ?
Some question:
So I(m going to start to move the dependencies from pear channel to github sources.
You d'ont use Comopser ? Because a rule missing: If comopser method exist, you SHOULD use it.
No ?
2014-03-08 8:05 GMT+01:00 Remi Collet Fedora@famillecollet.com:
Hi,
See : https://github.com/sebastianbergmann/phpunit/wiki/Release-Announcement-for-P...
This means that the PEAR channel is going to be deprecated.
So I(m going to start to move the dependencies from pear channel to github sources.
Already done for php-phpunit-Version https://github.com/remicollet/remirepo/commit/44d4e911d5abf05dbee29e65b70d58...
I have run some tests, phploc and phpcpd still work with this new package layout.
Probably we need some Guildelines to facilitate such migration.
My idea is:
pear package MUST (names from package.xml) Provides: php-pear(foo) = %{version} Requires: php-pear(bar) >= x.y
composer packages MUST (names from composer.json) Provides: php-composer(foo) = %{version} Provides: php-composer(foo) >= %x.z
composer packages SHOULD temporary provides Provides: php-pear(foo) = %{version}
composer packages MUST not Requires: php-pear(bar) >= x.y
This allow us to track (using repoquery) pear dependencies, and this temporary provides could be dropped when no more required.
Of course this have to happen mostly in rawhide.
Feedback ?
Remi.
P.S. as PHPUnit 3.7 is a LTS version, I plan to keep it for some time in Fedora <= 20 and EPEL <= 6. _______________________________________________ php-devel mailing list php-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/php-devel
Le 09/03/2014 08:26, Guillaume Kulakowski a écrit :
Hi,
Good idea. Is there a page for that in the Wiki ?
Some question:
So I(m going to start to move the dependencies from pear channel to github sources.
You d'ont use Comopser ? Because a rule missing: If comopser method exist, you SHOULD use it.
Must disagree.
There is only, for now, 2 types of package. - PEAR (the installer, using /usr/share/pear) - Tarball (sources, using /usr/share/php)
Composer is absolutely irrelevant for system wide packaging.
Only benefit we have is the (quite good) description of dependencies in the metadata file (composer.json). Nothing more.
So NO, I don't think we should prefer 1 method.
I think it sometine make sense to switch to "sources" (github or something else) instead of pear, when pear channel is no more maintained (sabredav) or very poorly maintained (symfony, phpseclib, ...). No other reason.
Remi.
No ?
2014-03-08 8:05 GMT+01:00 Remi Collet Fedora@famillecollet.com:
Hi,
See : https://github.com/sebastianbergmann/phpunit/wiki/Release-Announcement-for-P...
This means that the PEAR channel is going to be deprecated.
So I(m going to start to move the dependencies from pear channel to github sources.
Already done for php-phpunit-Version https://github.com/remicollet/remirepo/commit/44d4e911d5abf05dbee29e65b70d58...
I have run some tests, phploc and phpcpd still work with this new package layout.
Probably we need some Guildelines to facilitate such migration.
My idea is:
pear package MUST (names from package.xml) Provides: php-pear(foo) = %{version} Requires: php-pear(bar) >= x.y
composer packages MUST (names from composer.json) Provides: php-composer(foo) = %{version} Provides: php-composer(foo) >= %x.z
composer packages SHOULD temporary provides Provides: php-pear(foo) = %{version}
composer packages MUST not Requires: php-pear(bar) >= x.y
This allow us to track (using repoquery) pear dependencies, and this temporary provides could be dropped when no more required.
Of course this have to happen mostly in rawhide.
Feedback ?
Remi.
P.S. as PHPUnit 3.7 is a LTS version, I plan to keep it for some time in Fedora <= 20 and EPEL <= 6. _______________________________________________ php-devel mailing list php-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/php-devel
Provides: php-composer(foo) = %{version}
I really like this idea and meant to bring it up before. Most upstream pkgs are going the composer route and even if we don't create our downstream pkgs using composer we should at least be able to find them by it. I know personally this would have saved me time with one pkg that already existed!
Also, I would like to make sure "foo" = "vendor/project".
Can we start using this now or should we wait?
On Sun, Mar 9, 2014 at 4:18 AM, Remi Collet Fedora@famillecollet.comwrote:
Le 09/03/2014 08:26, Guillaume Kulakowski a écrit :
Hi,
Good idea. Is there a page for that in the Wiki ?
Some question:
So I(m going to start to move the dependencies from pear channel to github sources.
You d'ont use Comopser ? Because a rule missing: If comopser method exist, you SHOULD use it.
Must disagree.
There is only, for now, 2 types of package.
- PEAR (the installer, using /usr/share/pear)
- Tarball (sources, using /usr/share/php)
Composer is absolutely irrelevant for system wide packaging.
Only benefit we have is the (quite good) description of dependencies in the metadata file (composer.json). Nothing more.
So NO, I don't think we should prefer 1 method.
I think it sometine make sense to switch to "sources" (github or something else) instead of pear, when pear channel is no more maintained (sabredav) or very poorly maintained (symfony, phpseclib, ...). No other reason.
Remi.
No ?
2014-03-08 8:05 GMT+01:00 Remi Collet Fedora@famillecollet.com:
Hi,
See :
https://github.com/sebastianbergmann/phpunit/wiki/Release-Announcement-for-P...
This means that the PEAR channel is going to be deprecated.
So I(m going to start to move the dependencies from pear channel to github sources.
Already done for php-phpunit-Version
https://github.com/remicollet/remirepo/commit/44d4e911d5abf05dbee29e65b70d58...
I have run some tests, phploc and phpcpd still work with this new package layout.
Probably we need some Guildelines to facilitate such migration.
My idea is:
pear package MUST (names from package.xml) Provides: php-pear(foo) = %{version} Requires: php-pear(bar) >= x.y
composer packages MUST (names from composer.json) Provides: php-composer(foo) = %{version} Provides: php-composer(foo) >= %x.z
composer packages SHOULD temporary provides Provides: php-pear(foo) = %{version}
composer packages MUST not Requires: php-pear(bar) >= x.y
This allow us to track (using repoquery) pear dependencies, and this temporary provides could be dropped when no more required.
Of course this have to happen mostly in rawhide.
Feedback ?
Remi.
P.S. as PHPUnit 3.7 is a LTS version, I plan to keep it for some time in Fedora <= 20 and EPEL <= 6. _______________________________________________ php-devel mailing list php-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/php-devel
php-devel mailing list php-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/php-devel
Working on PHPUnit 4.0.x update, I'm working on the dependencies.
New dependency:
* php-phpunit-environment - Handle HHVM/PHP environments https://bugzilla.redhat.com/show_bug.cgi?id=1084753
Moving php-phpunit-exported from pear channel to github sources I notice the need to generate an autoloader (issue already encountered with Symfony packages).
A simple way to create a specfic autoloader for a library is the "phpab" command (PHP Autoloader Builder)
So, 2 new reviews
* php-theseer-directoryscanner - A directory scanner and filter https://bugzilla.redhat.com/show_bug.cgi?id=1084772
* php-theseer-autoload - A tool and library to generate autoload code https://bugzilla.redhat.com/show_bug.cgi?id=1084777
Exemple of use: https://raw.githubusercontent.com/remicollet/remirepo/4870f9e0b51097489263be...
Thanks for reviewing those small packages. Remi.
I have reviewed and approved 2 of the 3 packages. The other package hangs during a fedora-review run (I did not have time to debug).
=== Reviewed and approved === * php-phpunit-environment - Handle HHVM/PHP environments https://bugzilla.redhat.com/show_bug.cgi?id=1084753 * php-theseer-directoryscanner - A directory scanner and filter https://bugzilla.redhat.com/show_bug.cgi?id=1084772
=== fedora-review hangs === * php-theseer-autoload - A tool and library to generate autoload code https://bugzilla.redhat.com/show_bug.cgi?id=1084777
On Sun, Apr 6, 2014 at 10:24 AM, Remi Collet Fedora@famillecollet.comwrote:
Working on PHPUnit 4.0.x update, I'm working on the dependencies.
New dependency:
- php-phpunit-environment - Handle HHVM/PHP environments
https://bugzilla.redhat.com/show_bug.cgi?id=1084753
Moving php-phpunit-exported from pear channel to github sources I notice the need to generate an autoloader (issue already encountered with Symfony packages).
A simple way to create a specfic autoloader for a library is the "phpab" command (PHP Autoloader Builder)
So, 2 new reviews
- php-theseer-directoryscanner - A directory scanner and filter
https://bugzilla.redhat.com/show_bug.cgi?id=1084772
- php-theseer-autoload - A tool and library to generate autoload code
https://bugzilla.redhat.com/show_bug.cgi?id=1084777
Exemple of use:
https://raw.githubusercontent.com/remicollet/remirepo/4870f9e0b51097489263be...
Thanks for reviewing those small packages. Remi. _______________________________________________ php-devel mailing list php-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/php-devel
Le 13/04/2014 05:08, Shawn Iwinski a écrit :
I have reviewed and approved ...
Thanks for the reviews.
Work in progress: packages of PHPUnit dependencies are slowly moving from PEAR tarball to Github sources.
Already done (in rawhide and epel7): diff 1.1.0 environment 1.0.0 exporter 1.0.1 version 1.0.3
Each still provides the "autoload.php", used in the "pear" mode. When missing, this file is generated with the new "phpab" command (as upstream was used to generate them).
Please, notify me if you notice any issue. Other packages will change soon.
I hope to be able to update PHPUnit to 4.0.x before the summer.
Remi.
P.S. notice : the phpunit pear channel will be closed on Dec 31th.
Most PHPUnit components in rawhide/EPEL7 are now build from github sources (when compatible with PHPUnit 3.7).
Other packages are ready - PHPUnit 4.1 - PHP_CodeCoverage 2.0 - PHPUnit_MockObject 2.1 - phploc 2.0.5 - phpcov 2.0.0
Still TODO - bytekit (llaumgui) - phpcpd (llaumgui) - phpdcd (cdamian)
Of course, PHPUnit 4.1 (released May 2nd) introduce a new dependency https://bugzilla.redhat.com/show_bug.cgi?id=1093930 php-phpunit-comparator - Compare PHP values for equality
Packages are available in my "remi-test" repository.
Test / Feedback welcome.
Going to hit rawhide soon.
Remi.
All packages included PHPUnit 4.1 are now built from github sources and available in rawhide and epel7.
Remi
PHPUnit 4.2.0 is now available in f21/rawhide and epel7.
Remi.
php-devel@lists.fedoraproject.org