1. You can write original package names in BRs 

repoquery -qf "php(language)"
php-common-0:5.5.0-0.10.RC3.fc19.i686
php-common-0:5.5.4-1.fc19.i686

repoquery -qf "php-pear(pear.phpunit.de/PHPUnit)"
php-phpunit-PHPUnit-0:3.7.23-1.fc19.noarch
php-phpunit-PHPUnit-0:3.7.21-1.fc19.noarch

repoquery -qf "php-pear(pear.doctrine-project.org/DoctrineCommon)"
php-doctrine-DoctrineCommon-0:2.3.0-3.fc19.noarch

repoquery -qf "php-pear(pear.doctrine-project.org/DoctrineDBAL)"
php-doctrine-DoctrineDBAL-0:2.3.4-4.fc19.noarch

repoquery -qf "php-pear(pear.doctrine-project.org/DoctrineORM)"
php-doctrine-DoctrineORM-0:2.3.3-1.fc19.noarch

repoquery -qf "php-pear(pear.twig-project.org/Twig)"
php-twig-Twig-0:1.13.1-1.fc19.noarch
php-twig-Twig-0:1.13.2-1.fc19.noarch



2.When building got these messages : 

FAILURES!
Tests: 10707, Assertions: 21148, Failures: 5, Errors: 40, Skipped: 1016.

http://helallinux.com/paste/show.php?id=1264
Is that normal ?

THANKS for taking a quick look Mosaab! :)

This is a pretty complicated pkg so you may not want to start here ;)


(In reply to Mosaab Alzoubi from comment #1)
> 1. You can write original package names in BRs 
> 
> repoquery -qf "php(language)"
> php-common-0:5.5.0-0.10.RC3.fc19.i686
> php-common-0:5.5.4-1.fc19.i686
> 
> repoquery -qf "php-pear(pear.phpunit.de/PHPUnit)"
> php-phpunit-PHPUnit-0:3.7.23-1.fc19.noarch
> php-phpunit-PHPUnit-0:3.7.21-1.fc19.noarch
> 
> repoquery -qf "php-pear(pear.doctrine-project.org/DoctrineCommon)"
> php-doctrine-DoctrineCommon-0:2.3.0-3.fc19.noarch
> 
> repoquery -qf "php-pear(pear.doctrine-project.org/DoctrineDBAL)"
> php-doctrine-DoctrineDBAL-0:2.3.4-4.fc19.noarch
> 
> repoquery -qf "php-pear(pear.doctrine-project.org/DoctrineORM)"
> php-doctrine-DoctrineORM-0:2.3.3-1.fc19.noarch
> 
> repoquery -qf "php-pear(pear.twig-project.org/Twig)"
> php-twig-Twig-0:1.13.1-1.fc19.noarch
> php-twig-Twig-0:1.13.2-1.fc19.noarch

The standard guideline we use for Fedora is to use these virtual provides.  For minimal PHP version, we use "php(language)". For PEAR pkgs the format is "php-pear(CHANNEL/PKG)".

Here's all the guidelines we have documented: https://fedoraproject.org/wiki/Packaging:PHP



> 2.When building got these messages : 
> 
> FAILURES!
> Tests: 10707, Assertions: 21148, Failures: 5, Errors: 40, Skipped: 1016.
> 
> http://helallinux.com/paste/show.php?id=1264
> Is that normal ?

Yes, the failing PHPUnit tests are normal unfortunately.  They fail even when I manually run the tests on all of my test machines.  I added "|| : Temporarily ignore failed tests" in the %check section so the failing PHPUnit tests do not cause the building of the RPMs to fail though.

On the test section, you must add this peace of code into new source.

(In reply to Lameire Alexis from comment #3)
> On the test section, you must add this peace of code into new source.

?

> Yes, the failing PHPUnit tests are normal unfortunately.
> They fail even when I manually run the tests on all of my test machines.
>  I added "|| : Temporarily ignore failed tests" in the %check section so
> the failing PHPUnit tests do not cause the building of the RPMs to fail though.

I a bit uncomfortable with completely skipping the test result.

In previous multi-spec solution, the test of most of the component were ok. Only a few were ignored.

Skipping the test global result will not allow us to detect regression.

I should be possible to disable "only" the failed test ?
(during investigation with upstream on those failure)

@shawn: some interesting information in 
https://github.com/symfony/symfony/blob/master/.travis.yml

Perhaps a workaround (temp. excluding src/Symfony/Bundle) is

  for dir in src/Symfony/Component/*  src/Symfony/Bridge/*
  do
    echo -e "\n----- $dir ----\n"
    phpunit -d include_path=./src:.:/usr/share/php:/usr/share/pear \
      -d date.timezone=UTC --exclude-group tty,benchmark $dir
  done

From https://github.com/symfony/symfony/blob/master/composer.json
Perhaps some dependencies (requires-dev) are missing, which are needed for the some tests..

The "Fatal error: Class 'Symfony\Bundle\FrameworkBundle\FrameworkBundle' not found ..." could probably be explained... but don't see trivial explanation.

(In reply to Remi Collet from comment #5)

One of the biggest issues with the RPM build for the tests is that we are not using the Composer-generated autoload files which add more than just include path class loading.  Would you rather:
1) Continue to figure out our own solution without using Composer-generated autoload files
2) Generate the Composer autoload files and include them in the pkg (since we do not have a Fedora Composer pkg)

Thanks for pointing the exact problem: "this is not designed to be packaged".

Sorry, but you know my feeling about composer (bull-shit-to-create-broken-system), so I will try to not be too rude in my answer ;)

Most components are distributed via a pear channel, to be installed system-wide, and be used by other app. And it works, p.e: PHPUnit uses various Symfony2 component (and I haven't try yet how PHPUnit will react with symfony2 from outside pear channel, thus, with lot of pear broken dep).

For other things, (probably those which are not available in pear channel), this seems to means they are not designed for such usage (and honestly, afaik, upstream really don't care).

So if we are unable to provide a simple autoload mechanism for them, (and so, to run test unit), this mean that nobody will be able to use them, and so, that packaging have absolutely no sense.

If we package a framework, this is to be able to use it from a packaged web application (other people will very probably not even try to use it).

Ex : ZF2 is used by GLPI, and all works as expected, without any hack.

So for your proposal (2) sorry again, but I can't even imagine how this can be usable. "composer install" will pull all the needed dependencies, and install them in "vendor", exactly what we don't want (bundled-lib-factory) and what will happen is someone run "composer install" in this dir ?

So, yes (1) still for me the only way to go.

Please prove me that packaging this way (single spec vs per pear component spec) is really possible and have some sense.

I think(In reply to Shawn Iwinski from comment #0)
> * Intl requires Icu and Icu requires Intl so I'm not sure I can separate out
> the Icu pkg

I think is will be preferable to have a separate package for symfony2/Icu.

Especially as symfony2/Icu 1.2.0 requires libicu >= 4.4 which is not available in RHEL-6, so you will have to use symfony2/Icu 1.1.0 in EPEL-6.

Quick notes

ln -s %{name}-common-%{version} %{buildroot}%{_docdir}/%{name}-%{version}

This will not work on Fedora >= 20
See https://fedoraproject.org/wiki/Changes/UnversionedDocdirs

(In reply to Remi Collet from comment #8)
> I think(In reply to Shawn Iwinski from comment #0)
> > * Intl requires Icu and Icu requires Intl so I'm not sure I can separate out
> > the Icu pkg
> 
> I think is will be preferable to have a separate package for symfony2/Icu.
> 
> Especially as symfony2/Icu 1.2.0 requires libicu >= 4.4 which is not
> available in RHEL-6, so you will have to use symfony2/Icu 1.1.0 in EPEL-6.

I tried the separation of the Icu component and it was a huge pain so I kept it in the same pkg.



(In reply to Remi Collet from comment #9)
> ln -s %{name}-common-%{version} %{buildroot}%{_docdir}/%{name}-%{version}
> 
> This will not work on Fedora >= 20
> See https://fedoraproject.org/wiki/Changes/UnversionedDocdirs

Fixed



Updated:
- Different Icu component version for el6
- Fixed tests:
-- Updated autoloader
-- Skipped specific tests
-- Excluded tty and benchmark test groups
- I liked the individual pkg tests instead of the all-in-test so each pkg's tests are run individually (this includes all pkgs... bridges, bundles, and components)
- Fixed main package doc symlink

Koji scratch builds:
rawhide: http://koji.fedoraproject.org/koji/taskinfo?taskID=6144362
f20: http://koji.fedoraproject.org/koji/taskinfo?taskID=6144368
f19: http://koji.fedoraproject.org/koji/taskinfo?taskID=6144385
el6: http://koji.fedoraproject.org/koji/taskinfo?taskID=6144408

Update diff (ignore the php-gliph stuff): https://github.com/siwinski/rpms/compare/97c1aa41297efdbddeb4e522714de3245fd47f87...3e70be4eada4b08f2d9319f4956138a8a3b5cb76



Spec URL: https://raw.github.com/siwinski/rpms/3e70be4eada4b08f2d9319f4956138a8a3b5cb76/php-symfony2.spec

SRPM URL: http://siwinski.fedorapeople.org/SRPMS/php-symfony2-2.3.6-2.fc19.src.rpm
(el6: http://siwinski.fedorapeople.org/SRPMS/php-symfony2-2.3.6-2.el6.src.rpm)

Result is much better :) as test suite is useful

FYI: https://admin.fedoraproject.org/updates/php-password-compat-1.0.0-5.git58151cf.el6

Just a small problem: sources should not be conditionalized.

You could have provided 2 spec files, a fedora specific one and another for  epel-6. This were fine.

You can also provide a generic spec file for all branches. This is fine and acceptable. But in this case the spec must really be generic, so the .src.rpm must include all sources and patches to be usable on all branches (else, among other bad side effects, git merge/cherry-pick will not work, because of conflict on the "sources" files).

So you need to have Source1 for Icu 1.1.0 and Source2 for Icu 1.2.0 and only use %{?el6} for %setup

Tips: I think you can even use (as I think testing icu version is closer to upstream documented depencency). Of course this need BR pkgconfig(icu-i18n)

if pkg-config icu-i18n --atleast-version=4.4
then tar xzf %{SOURCE1} --strip-components 1
else tar xzf %{SOURCE2} --strip-components 1
fi

Another minor issue using the same .src.rpm for symfony2 and icu. 
On symfony2 update, you will have to manage NVER of icu (you cannot use the same).

So, for example:
php-symfony2-2.3.6-2     => php-symfony2-2.3.7-3
php-symfony2-icu-1.2.0-2 => php-symfony2-icu-1.2.0-3

So, you will be able to set release = 1 only when both versions change.
A bit tricky

*** NOTE: This pkg BR php-symfony2-icu (bug 1031400)

- Updated to 2.3.7
- Separated icu pkg
- Added php-password-compat requires for el6 (PHP < 5.5.0)
- common sub-pkg now owns %%{symfony_dir}/{Bridge,Bundle,Component}
- Fixed classloader URL

Update diff: https://github.com/siwinski/rpms/compare/3e70be4eada4b08f2d9319f4956138a8a3b5cb76...55c9f9e4e932e4b04d6a765fbee023f5c2df458f



Spec URL: https://raw.github.com/siwinski/rpms/55c9f9e4e932e4b04d6a765fbee023f5c2df458f/php-symfony2.spec

SPM URL: http://siwinski.fedorapeople.org/SRPMS/php-symfony2-2.3.7-1.fc19.src.rpm

Typo:
-Requires:  php-pear(pear.swiftmailer.org/Swift) >  %{swift_max_ver}
+Requires:  php-pear(pear.swiftmailer.org/Swift) <  %{swift_max_ver}

Tips for phpunit option (I discover this recently, often simpler)

Instead of
    -d include_path="./src:%{_datadir}/php:%{pear_phpdir}" \

Use 
    --include-path=./src \

Perhaps you should also Obsoletes php-channel-symfony2 from php-symfony2-common (as this package have probably no reason to be kept)

Created attachment 825642 [details]
phpci.log

phpcompatinfo version 2.25.0.

Created attachment 825643 [details]
review.txt

Generated by fedora-review 0.5.0 (920221d) last change: 2013-08-30
Command line :/usr/bin/fedora-review -b 1031400
Buildroot used: fedora-19-x86_64
Active plugins: Generic, PHP, Shell-api
Disabled plugins: Java, C/C++, Python, SugarActivity, Perl, R, Ruby
Disabled flags: EPEL5, EXARCH, DISTTAG

Update from installed packages (pear ones) to new packages => ok.

PHPUnit still works (despite pear metadata are now inconsistent)

Packages which requires another php-symfony2-* don't need to requires -common (not a blocker), with explicit dependency policy... metadata are already so huge...


Issues:
=======
[!]: Installation fails
	Wait for php-symfony2-icu approval before import

[!]: Requires correct, justified where necessary.
	-Requires:  php-pear(pear.swiftmailer.org/Swift) >  %{swift_max_ver}
	+Requires:  php-pear(pear.swiftmailer.org/Swift) <  %{swift_max_ver}

Same comment as for symfony/icu.

What do you think of using php-symfony prefix instead of php-symfony2 ?

I forget, in the description of the main package "PHP full-stack web framework ".
I think "full" can be ambiguous (as the meta-package don't install the full famework...). Any better proposal ?

Spec

(In reply to Remi Collet from comment #21)
> I forget, in the description of the main package "PHP full-stack web
> framework ".
> I think "full" can be ambiguous (as the meta-package don't install the full
> famework...). Any better proposal ?

Updated with text from http://symfony.com/

- Renamed from "php-symfony2" to "php-symfony"
- Updated main pkg summary
- Removed dependency on common sub-pkg for sub-pkgs that require other sub-pkgs
- Common sub-pkg obsoletes php-channel-symfony2
- Fixed swiftmailerbridge sub-pkg dependency
- Updated %%check to use PHPUnit's "--include-path" option


Spec URL: https://raw.github.com/siwinski/rpms/de1b10361eacd711796a1f5c540a9961bfdaf2b6/php-symfony.spec

SRPM URL: http://siwinski.fedorapeople.org/SRPMS/php-symfony-2.3.7-2.fc19.src.rpm

*** Bug 979793 has been marked as a duplicate of this bug. ***

*** Bug 979794 has been marked as a duplicate of this bug. ***

Blocker fixed.

Notice: you have change from Symfony2 to Symfony is "most" package, you only

Summary:   Symfony2 common files

You also have Symfony2 in some description.
This are only minor typo which can be fixed afer import.

==== APPROVED ====

THANKS for the review and all of the help!


New Package SCM Request
=======================
Package Name: php-symfony
Short Description: PHP framework for web projects
Owners: siwinski remi
Branches: f19 f20 el6
InitialCC:

Git done (by process-git-requests).

php-symfony-2.3.7-3.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/php-symfony-2.3.7-3.fc20

php-symfony-2.3.7-3.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/php-symfony-2.3.7-3.el6

php-symfony-2.3.7-3.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/php-symfony-2.3.7-3.fc19

php-symfony-2.3.7-3.fc20 has been pushed to the Fedora 20 testing repository.

Please don't push the package prior to retiring the obsolete packages:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

If that is not done properly, typically someone submits an update with a newer EVR that breaks existing Obsoletes tags.

@Michael, for thi package, the new "must" be puhsed before retiring the old.

Symfony is a dep of PHPUnit which is used by a lot of PHP packages, 
having a broken deps will forbid any new build...

Adding F20FinalFreezeException/FinalFreezeException

php-symfony2-* packages have been retired from F20, bosoleted by this one, so:

php-phpunit-PHPUnit has broken dependencies in the F-20 tree:
	php-phpunit-PHPUnit-3.7.28-1.fc20.noarch requires php-pear(pear.symfony.com/Yaml) >= 0:2.0.0

php-phpunit-DbUnit has broken dependencies in the F-20 tree:
	php-phpunit-DbUnit-1.3.0-1.fc20.noarch requires php-pear(pear.symfony.com/Yaml) >= 0:2.1.0

php-phpunit-FinderFacade has broken dependencies in the F-20 tree:
	php-phpunit-FinderFacade-1.1.0-2.fc20.noarch requires php-pear(pear.symfony.com/Finder) >= 0:2.2.0


As PHPUnit is BR of lot of packages (to run UnitTest during %check) this packages are mandatory for F20Final.

php-symfony-2.3.7-3.fc19 has been pushed to the Fedora 19 stable repository.

Proposed as a Freeze Exception for 20-final by Fedora user remi using the blocker tracking app because:

 PHPUnit is broken because php-symfony2-* habe be retired "before" php-symfony-* have be pushed.

PHPUnit is used by lot of PHP packages, during %check

+1 FE, assuming dependent packages are on the DVD. and please, mschwendt, don't retire *anything* during release freeze without triple-checking it.

Why can this not be released as an 0 day update?

@Johann, please read above history.

Because of too much much broken deps in the PHP stack.

Discussed in 2013-12-11 Blocker Review Meeting [1]. Voted an AcceptedFreezeException. This is at least FE. blocker status depends on whether it affects any package on the DVD; we will determine and update status after the meeting.

[1] http://meetbot.fedoraproject.org/fedora-blocker-review/2013-12-11/

The fix is already in RC1, removing blocker nomination.

php-symfony-2.3.7-3.fc20 has been pushed to the Fedora 20 stable repository.

php-symfony-2.3.7-3.el6 has been pushed to the Fedora EPEL 6 stable repository.