Bug 421241 - Review Request: php-ZendFramework - Leading open-source PHP framework
Summary: Review Request: php-ZendFramework - Leading open-source PHP framework
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Gianluca Sforna
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 439015 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-12-12 11:39 UTC by Alexander Kahl
Modified: 2014-10-13 22:57 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-08-07 09:49:45 UTC
Type: ---
Embargoed:
giallu: fedora-review+
kevin: fedora-cvs+


Attachments (Terms of Use)
Test run on ZendFramework 1.5.2 with PHPunit (150.37 KB, application/octet-stream)
2008-06-11 22:37 UTC, Alexander Kahl
no flags Details

Description Alexander Kahl 2007-12-12 11:39:48 UTC
Spec URL: http://prelive.iconmobile.com/dev31/fedora-icm-repo/Fedora/8/SPECS/php-ZendFramework.spec
SRPM URL: http://prelive.iconmobile.com/dev31/fedora-icm-repo/Fedora/8/SRPMS/php-ZendFramework-1.0.3-1.fc8.src.rpm
Description: 
Extending the art & spirit of PHP, Zend Framework is based on simplicity,
object-oriented best practices, corporate friendly licensing, and a rigorously
tested agile codebase. Zend Framework is focused on building more secure,
reliable, and modern Web 2.0 applications & web services, and consuming widely
available APIs from leading vendors like Google, Amazon, Yahoo!, Flickr, as
well as API providers and catalogers like StrikeIron and ProgrammableWeb.

Comment 1 Jason Tibbitts 2007-12-22 06:28:57 UTC
I'm getting a 502 proxy error trying to access the above links.

Comment 2 Alexander Kahl 2007-12-27 17:13:22 UTC
Sorry - the host will be available again on January 2.

Comment 3 Gianluca Sforna 2007-12-27 20:03:14 UTC
I had a chance to briefly look at the spec file before it went down, and I think
you should consider splitting the package in several subpackages, possibly at
the "component" granularity as described in:

http://framework.zend.com/manual/components

it will be more work but otherwise you loose one of the big win of the
Framework, that is, components are loosely coupled so it's possible to "pick"
only the ones required for a given work.

Comment 4 Alexander Kahl 2008-02-15 20:18:07 UTC
Gianluca,

I guess you're right. However I'll need some time to get this done as many spec
files and subsequent package review requests are needed thus I'm removing this
request for now.

Comment 5 Gianluca Sforna 2008-02-16 21:45:46 UTC
Well, if you want to defer this it is ok. 

However, please note you just need one spec and one review. I was only
suggesting that the single spec file would build a number of binary RPMS instead
of a single one.

This is done in several other packages and (more or less) detailed in
http://docs.fedoraproject.org/drafts/rpm-guide-en/ch10s04.html

Comment 6 Alexander Kahl 2008-03-17 11:18:52 UTC
Reopening.

Updated SPEC URL:
http://akahl.fedorapeople.org/php-ZendFramework/php-ZendFramework.spec

Updated SRPM URL:
http://akahl.fedorapeople.org/php-ZendFramework/php-ZendFramework-1.5.0-1.fc8.rc3.src.rpm

--

Since 1.5.0 is about to reach stable, I'm using the release candidates series
for now. All components are split up into subpackages with interdependencies
resolved via manual search and unit tests applied. All components have virtual
requires and provides in the php-Zend(x) namespace.
All significant rpmlint warnings and errors refer to files that are needed by
the unit tests (subpackage -tests) and must not be modified in the distribution,
otherwise complex patches to the tests have to be created and maintained.

One issue remaining is that some unit tests explicitly try to create a cache
directory (grep for cache_dir) locally below their _files directories, thus
failing. Simply symlinking each _files directory below
/var/tmp/php-Zendframework is not a clean solution since most of those already
contain static test data so maybe /var/lib would be a better candidate. Any
suggestions here are welcome.

Comment 7 Alexander Kahl 2008-03-17 17:53:40 UTC
Seems like I missed the final release just by a few minutes.

Updated SPEC URL:
http://akahl.fedorapeople.org/php-ZendFramework/php-ZendFramework.spec

Updated SRPM URL:
http://akahl.fedorapeople.org/php-ZendFramework/php-ZendFramework-1.5.0-1.fc8.src.rpm


Comment 8 Seth Vidal 2008-04-03 16:10:43 UTC
As mentioned on this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=439015

maybe y'all can collaborate on one packaging of this?



Comment 9 Alexander Kahl 2008-04-04 08:04:46 UTC
*** Bug 439015 has been marked as a duplicate of this bug. ***

Comment 10 Gianluca Sforna 2008-05-19 23:16:29 UTC
Alexander, did you get in touch with Jess Portnoy from Zend to see if you can
work together on the package? I guess he could have some insights to fix the
test issue.

Alternatively, you could post on fedora-devel or fedora-packaging to ask for
help on the issue; chances are that's not a blocking one.

Comment 11 Jess Portnoy 2008-05-20 06:56:50 UTC
Hi Alexander,

Would be happy to collaborate with you.
Please contact me at: jess at zend.com and we can discuss this further.

Thanks,

Comment 12 Jess Portnoy 2008-05-20 16:56:04 UTC
About the problem with the getTmpDir() function in the unit tests, I think a
good solution would be to allow overriding of the default TMPDIR [currently
evaluated from: dirname(__FILE__)/zend_cache_tmp_dir], maybe as an ENV var or
better yet, a directive in Zend/tests/Zend/Config/_files/config.ini. This way,
it can be set to a convenient location, sort of the same idea as the TMPDIR ENV
variable.

Does that sound reasonable to you?

I will discuss it with the Zend Framework developers and keep you posted.

Comment 13 Gianluca Sforna 2008-05-20 22:37:08 UTC
oh, and in the meanwhile 1.5.2 is out

Comment 14 Alexander Kahl 2008-05-21 11:14:27 UTC
Hi Jess,

thank you for helping me here. For the review request the latest stable version
has to be packaged always so I need to update for 1.5.2 first, as Gianluca
mentioned.
The config.ini solution sounds most reasonable to me as this requires only a
single file to be provided or patched once in Fedora's package. On the other
hand, using ENV only would require a user to properly set his environment first,
i.e. it doesn't work out of the box and requires providing a special
README.fedora file. Will the config.ini be part of 1.5.3?

The other issue are the subpackages: Do you know any feasible way to accomplish
interdependency determination between the components of the framework,
preferably programmatic? Wil is concerned here, although I'm pretty optimistic
my method of unit testing each component individually and isolated suffices as
long as code coverage is near complete - I think this process could be automated
as well utilizing mock, our package building chroot tool.
We (the Fedora community) emphasize high package quality implying high
granularity and removing redundancy where reasonable/possible. If you are
certain that splitting up Zend Framework brings more problems than benefits,
I'll remove the split. 
From my personal experience with the framework, many components can be used
either individually or pulling in only few dependencies. Especially I don't see
why everyone must have all Zend_Service:s installed as many rely on registration
with the service providers and/or are very specific.


@Gianluca
Would you volunteer for the review? Zend Framework release cycles are pretty
tight and the faster we get this into Fedora, the less work will finally be
wasted in case the subpackages stay (doesn't mean to review less thoroughly than
usual though).

Comment 15 Jess Portnoy 2008-05-21 12:30:11 UTC
Hi Alexander,

In general, I am all for segmentation but I think here it's a bit over
segmented. For instance, I think there's much sense in placing the unit tests
and demos in separate RPMs. Maybe it would make more sense to group modules into
a few meta packages? This way, you could have a package of "common" modules,
another for demos, a third for unit tests and poteniotally a few other extra
packages containing less popular modules. This way, the user won't have to go
through a huge list of packages related to the framework but, on the other hand,
won't have many redundant packages he will never use.
Does that sound reasonable?

Comment 16 Brad Walker 2008-05-22 03:16:35 UTC
My $0.02:

I also think it's over-segmented, currently counting 59 packages. The only
reason I'd want ZF segmented is to control which binary dependencies yum
installs. I don't mind the bloat of PHP source files but I might not want
certain extensions installed. How about using the packages' extension
dependencies as a guide to grouping them?

Extension dependencies:
http://framework.zend.com/manual/en/requirements.extensions.html

All the Zend_Service packages can definitely go in one package. That alone takes
care of eleven subpackages.

Comment 17 Alexander Kahl 2008-05-23 11:32:07 UTC
Hi Jess, hi Brad,

taking both of your inputs into consideration I propose the following package
setup:

- php-ZendFramework (base package)
  Contains all commonly used modules including the MVC components and all
  non-base components not requiring additional binary modules (PHP extensions)
  Pulls in php-ctype, php-xml
- php-ZendFramework-Services
  Contains Zend_Service* excluding those listed below, base package and
  per-service provider subpackages
  Pulls in php-soap
- php-ZendFramework-Cache-Backend-Apc
  Pulls in php-pecl-apc
- php-ZendFramework-Locale-Math
  Pulls in php-bcmath
- php-ZendFramework-Search-Lucene
  Pulls in nothing as php-pecl-bitset doesn't seem to be available for Fedora
  (yet) but extra package anyway as it is not commonly used (I guess)
- php-ZendFramework-Http-Client-Adapter-Curl
  Pulls in php-curl
- php-ZendFramework-Pdf
  Pulls in php-gd
- php-ZendFramework-Db-Adapter-Db2
  Same situation as with Zend_Search_Lucene, ibm_db2 not available as of now
  (proprietary?)
- php-ZendFramework-Db-Adapter-Firebird
  Same as Zend_Search_Lucene, no i(nter)base
- php-ZendFramework-Feed
  Pulls in php-mbstring
- php-ZendFramework-Cache-Backend-Memcached
  Pulls in php-pecl-memcache
- php-ZendFramework-Db-Adapter-Mysqli
  Pulls in php-mysql (also contains mysqli)
- php-ZendFramework-Db-Adapter-Oracle
  Its required extension is proprietary but available in the free beer manner,
  we can either drop it or require the user to take care of the dependency
  manually
- php-ZendFramework-Db-Adapter*
  Pull in php-pdo
- php-ZendFramework-Cache-Backend-Sqlite
  Fedora's PHP was complied with --without-sqlite and I can only find the PDO
  driver, drop the component or file a bug against php..?
- php-ZendFramework-tests
- php-ZendFramework-demos
(php-ZendFramework-manual-en and -api-doc are submitted as separate packages /
review requests already)

One problem with Zend_Http_Client: I don't know about mime_magic (cannot find
it) and it's declared deprecated, can it use php-pecl-Fileinfo automatically
instead?

The following required extensions are included with Fedora's PHP by default
already:
dom, hash, iconv, json, pcre, posix, Reflection, session, SimpleXML, SPL,
standard, zlib

Any suggestions? The setup still looks pretty cluttered, maybe you've got
another idea for the grouping details.

Please take note that I will be on vacation and thus unavailable for one week
starting tomorrow, details are at
http://fedoraproject.org/wiki/Vacation

Comment 18 Jess Portnoy 2008-05-24 16:20:50 UTC
Hi Alexander,

This package segmentation seems better.
I think all php-ZendFramework-Db-Adapters can be included in one package, though
it is true one would usually need only one or maximum two of these. Maybe it's
better to have all common DBs in one package which requires php-pdo and the rest
in another package. This would mean you will install the Oracle stuff even if
you only want to use DB2 which is not so nice but on the other hand, there's
something logical about deviding the whole DB support into common and misc DBs.
I think most PHP developers use PDO to access MySQL, PGSQL, SQLite, etc and a
substantial lesser amount of developers use DB2 and OCI8 directly so the
separation makes sense. MySQLi is somewhat hard to decide upon because it does
not belong with the PDO and is pretty commonly used... I admit I am not sure as
to whether it should be in it's own package or included somewhere else.

About mime_magic, it is true that php.net declares it as deprecated by Fileinfo
from PECL but their APIs are not entirely compatible and I think many people
still use mime_magic. It's source is included in the PHP 5.2.6 [latest stable]
source tree under ext/mime_magic and it would be very easy to make an RPM out of
it. I will send you a spec file shortly.

Comment 19 Jess Portnoy 2008-05-24 16:44:52 UTC
About mime_magic, after a second look: it seems that it's quite easy to keep
using existing code originaly coded for mime_magic without changes as all you
need to do is add one compatibility wrapper function. As stated in
ext/mime_magic/DEPRECATED.
Since it is so, I will discuss this matter with the ZF developers. I think the
best thing would be to include this wrapper function in the event we have the
Fileinfo extension loaded and not mime_magic and so it will be able to use both.

Does this sound logical to you?

Comment 20 Gianluca Sforna 2008-05-24 22:51:49 UTC
(In reply to comment #14)
> @Gianluca
> Would you volunteer for the review? Zend Framework release cycles are pretty
> tight and the faster we get this into Fedora, the less work will finally be
> wasted in case the subpackages stay (doesn't mean to review less thoroughly than
> usual though).

Well, given my interest in using the framework, I think I could go for it.
Just ping me when the next iteration of the package is available


Comment 21 Jess Portnoy 2008-05-25 06:00:38 UTC
Thank you, Gianluca. Will do. I am waiting for a new version which will include
my patch to getTmpDir()  and my suggested fix for the mime_magic issue. As soon
as it's done we can go forward.

Comment 22 Alexander Kahl 2008-06-03 20:15:03 UTC
Hi Jess,

this is my status:

Current packages
  (base)
  demos
  tests
  Cache-Backend-Memcached
  Cache-Backend-Sqlite
  Db-Adapter-Mysqli
  Db-Adapter-Db2
  Db-Adapter-Firebird
  Db-Adapter-Oracle
  Feed
  Gdata (why doesn't this exist as a service component?)
  Pdf
  Search-Lucene
  Services

There are some issues here:
Cache-Backend-Sqlite requires php-sqlite but this is not available in Fedora's
PHP build, it was disabled Mon Nov 8 2004 by Joe Orton, most probably in favor
of pdo-sqlite. Can the back end handle pdo-sqlite instead of sqlite? If not we
probably have to exclude it.

Db-Adapter-Db2, Db-Adapter-Firebird and Db-Adapter-Oracle require extensions
that must be compiled in while having the respective database software
installed, in case of DB2 and Oracle this is impossible for Fedora since they
are proprietary software, I don't know about InterBase/Firebird however it's
also missing. We can of course offer Zend's adapters but the user is required to
compile PHP and enable the affected dependencies himself.

Feed has been separated because it requires mbstring; same goes for Pdf because 
of GD, Search-Lucene because of bitset; Locale-Math has _not_ been separated as
planned since Date uses bcmath as well and cannot be separated as a major
dependency for other base components.

About mime_magic: I've checked our PHP build, the extension was disabled Wed Mar
21 2007, indeed in favor of Fileinfo. I'd really appreciate Fileinfo support
from your side! A wrapper functions sounds completely reasonable.

The total list of extensions required for the base framework package as of now:
bcmath, ctype, curl, dom, hash, iconv, json, pcre, posix, reflection, session,
simplexml, spl, zlib.
Only two of them, bcmath and dom, require additional extensions to be pulled
in which is pretty acceptable.

About the getTmpDir() issue: Please keep in mind you're targeting a multi-user
platform, setting a fixed value in a configuration file can still create
clashes, especially if no cleanup is performed afterwards. Given both choices
only, I'd rather go with the environment variable; if you want a much more     
                                                                               
                                                  
flexible solution involving the configuration file, I suggest append a hash,
timestamp or the uid to the base path given. Actually this is what I do in my
tests :)
Alternatively, you could go with world writable modes for all files and
directories created during the tests.


@Gianluca
Thanks in advance for volunteering!

Comment 23 Jess Portnoy 2008-06-04 07:52:11 UTC
Hi Alexander,

About SQLite and the proprietary DB extensions, I think it's perfectly OK for
the user to take care of the missing deps should he so desire. The unit tests
themselves always check whether the extensions required are loaded and throw an
exception if they're not so the user can easily tell what's required and take
care of it. I see no problem with it as there are over 100 PHP extensions,
naturally you can't provide them all.

About getTmpDir(), I suggested:

return getenv('TMPDIR').DIRECTORY_SEPARATOR . 'zend_cache_tmp_dir_'.date("mdyHis");

This way, the directory will be created with a timestamp which will avoid
conflicts just as you suggested.

I have also submitted a wrapping function to the ZF developers and am now
waiting for them to apply both the getTmpDir() patch and this wrapper.

Comment 24 Alexander Kahl 2008-06-05 19:11:37 UTC
Hi Jess,

I will ask on fedora-devel how to handle absent or unavailable package
requirements when providing the requiring package makes sense. Could be that it
is not possible to provide the affected extensions at all because I (as the
would-be package maintainer) cannot provide support (verifying/fixing bugs etc.)
for them without non-Fedoran packages.

Your getTmpDir() solution looks perfectly suitable to solve all issues
identified so far, thank you!

Comment 25 Jess Portnoy 2008-06-10 08:27:59 UTC
Hi Alexander,

Are there any additional extensions are you missing in the FC repo besides
mime_magic and third party, non open DB vendors?

About the getTmpDir() function, it has been patched but unfortunately not quite
as I suggested, it's pretty close to my original suggestion but it only supports
exporting TMPDIR for now, my config.ini idea, where a directive could be set to
use an alternative tmpdir is not yet implemented. I think this will do for now
but I hope it can be implemented in the future. For now, we could just export
TMPDIR.

The change is available from ZF's SVN trunk:
http://framework.zend.com/svn/framework/standard/trunk/

About mime_magic vs. fileinfo, my wrapper function was not yet applied but I
will become a ZF committer soon and just apply it myself.

Please let me know how you did with getTmpDir().

Comment 26 Alexander Kahl 2008-06-11 22:37:52 UTC
Created attachment 309009 [details]
Test run on ZendFramework 1.5.2 with PHPunit

PHP 5.2.5 (cli) (built: Apr 24 2008 10:37:47)
PHPUnit 3.2.19

shell$ phpunit -d memory_limit=512M --verbose AllTests.php \
 > ~/ZendFramework-1.5.2-testall-$(date +%F)-tap.log 2>&1

All packages and dependencies identified so far were installed.

Comment 27 Alexander Kahl 2008-06-11 22:45:25 UTC
Hi Jess,

as you can see in above's comment I've attached the log from a complete 1.5.2
test run, maybe this is helpful to you.

(In reply to comment #25)
> Are there any additional extensions are you missing in the FC repo besides
> mime_magic and third party, non open DB vendors?
Surprisingly, yes: php-bitset (php-pecl-bitset) is not available for Fedora.
Pecl says someone from Zend maintains it but there has never been an update
after initial release in 2005. What are the drawbacks of using Search_Lucene
without bitset? Is it still considered maintained?
If not, becoming the packager of php-pecl-bitset would also mean becoming the
maintainer in Fedora World and I don't have any spare capacities to cope with
this. Otherwise, i.e. if Zend is still maintaining it, I'd package it.


> About the getTmpDir() function, it has been patched but unfortunately not quite
> as I suggested, it's pretty close to my original suggestion but it only supports
> exporting TMPDIR for now, my config.ini idea, where a directive could be set to
> use an alternative tmpdir is not yet implemented. I think this will do for now
> but I hope it can be implemented in the future. For now, we could just export
> TMPDIR.
This improves our situation of testing most components properly right now but I
wouldn't consider it the final solution. Our goal should be to have a blank
PHPunit run on AllTests.php walk through after a fresh installation without any
failures and/or errors.

> The change is available from ZF's SVN trunk:
> http://framework.zend.com/svn/framework/standard/trunk/
I've just checked out the trunk but will make an inspection and test run tomorrow.
 
> About mime_magic vs. fileinfo, my wrapper function was not yet applied but I
> will become a ZF committer soon and just apply it myself.
Sounds good.
 
> Please let me know how you did with getTmpDir().
Will do next time.

Comment 28 Jess Portnoy 2008-06-12 07:52:35 UTC
Hi Alexander,

About bitset, the person listed as maintainer no longer works at Zend. I don't
believe it will be maintained further. However, the use of bitset is not
mandatory. Comment in library/Zend/Search/Lucene/Index/SegmentInfo.php on line
167 reads:
bitset if bitset extension is loaded or array otherwise.

Therefore it is possible to use w/o having bitset loaded. This is also true to
mime_magic, BTW.

I will review your log and see what I can do about it.

Comment 29 Jess Portnoy 2008-06-12 08:14:31 UTC
Hello again,

I reviewed the log and the good news are most of the problems are mostly around
the same lines of the getTmpDir(), that is, the tests are trying to create and
manipulate files within the ZF tree which a normal user cannot do if the tree is
located under /usr/share.
The problem here is more vast than just getTmpDir() it appears as though the
entire concept was not considered when the tests were designed.

I will discuss it with the ZF developers and see how fast we can address this.

Thanks,


Comment 30 Alexander Kahl 2008-07-01 20:35:27 UTC
Hi Jess, any news?

I just did a test run on revision 9862 but getTmpDir() doesn't seem to be in
usage yet with the exception of a few optional tests.

Regards
Alex

Comment 31 Jess Portnoy 2008-07-03 08:43:45 UTC
Hi Alex,

Regarding the permissions issue, which is cross wide and not only specific to
the cache component as was quite obvious from the report you attached, I am
still waiting for the ZF maintainers to come up with a general fix. I have
explain the issue to them and suggested a few options to fix this. 
The mime_magin vs. fileinfo issue is suppose to be resolved. Please see:
http://framework.zend.com/issues/browse/ZF-3320
For more inforamtion.

I will, of course, notify you as you soon as they release a version that does
not suffer from these issues.
For now, can you please verify the Zend/Http/Client.php fix?

Thanks,

Comment 32 Gianluca Sforna 2008-07-03 09:10:40 UTC
Sorry guys, I'm a bit lost by now...

Are the remaining issues really a blocker or we can go ahead with the review in
the meanwhile?

Comment 33 Jess Portnoy 2008-07-03 10:42:26 UTC
Well, I don't want to speak on Alex's behalf but this is how I see our status:

0. The mime_magic vs. fileinfo issue is resolved [assuming it works well]
1. About the unit tests, some of them work properly, some do not due to
permissions issues. I don't think this is a show stopper, it should most
certainly be fixed but I think we can release the first RPM version as is and
work on it as we go along. The problem here is not periodic and I am trying to
motivate the ZF maintainers to address it.

Alex, are there any other issues I can help promote?

Thanks,

Comment 34 Alexander Kahl 2008-07-06 12:58:19 UTC
Hi Jess, hi Gianluca,

(In reply to comment #31)
> For now, can you please verify the Zend/Http/Client.php fix?
I've just verified this in HEAD: With php-Fileinfo installed, the correct mime
type is returned; without, the default (application/octet-stream). I consider
this fixed and not having this feature in 1.5.2 yet is definitely not a blocker
issue.

There's one minor non-blocker issue you could actually try to promote: Since
Zend has decided to not only provide a zipped version of the framework but also
a tarball which is most likely meant to target platforms like Fedora
(UN*X-likes), please fix file permissions before every release. In 1.5.2, all
Gdata-related files have their executable bit set. Right now, this needs to be
handled by my installation script.

Gianluca: I consider all previous blockers fixed and will upload a 1.5.2 package
right away.

Comment 35 Alexander Kahl 2008-07-06 13:04:18 UTC
Updated SPEC URL:
http://akahl.fedorapeople.org/php-ZendFramework/php-ZendFramework.spec

Updated SRPM URL: 
http://akahl.fedorapeople.org/php-ZendFramework/php-ZendFramework-1.5.0-1.fc8.rc3.src.rpm

Changes:
- update to 1.5.2
- new package split
- removed Cache-Backend-Sqlite, Db-Adapter-Db2, Db-Adapter-Firebird,
  Db-Adapter-Oracle
- removed optional php-bitset requirement from Search-Lucene, not available
- removed virtual requires and provides, not necessary anymore


Comment 36 Alexander Kahl 2008-07-06 13:05:08 UTC
Oops, old package URL.
Correct one:
http://akahl.fedorapeople.org/php-ZendFramework/php-ZendFramework-1.5.2-1.fc9.src.rpm


Comment 37 Jess Portnoy 2008-07-06 15:43:52 UTC
Hi Alex and Gianluca,

Just wanted to let you know the ZF team will release the 1.6 version in approx.
2 weeks. It will include the patches for both the mime_magic/fileinfo and the
fix for the cache unit test. I have also written to them about the package
permissions issue [the executable bit being turned on where it is not needed]
and I asked for them to fix it.


Comment 38 Jess Portnoy 2008-07-23 16:19:42 UTC
Hey Alex and Gianluca,

ZF 1.6RC1 is out. This includes the fix for the mime_magic-fileinfo issue.
The unit tests issue is not yet addressed unfortunately but the ZF developers
are aware of it.

Thanks,

Comment 39 Gianluca Sforna 2008-07-24 06:53:04 UTC
OT: too bad http://www.zendframework.com/issues/browse/ZF-2624 is still open ;)

Comment 40 Alexander Kahl 2008-07-29 08:11:14 UTC
Updated SPEC URL:
http://akahl.fedorapeople.org/php-ZendFramework/php-ZendFramework.spec

Updated SRPM URL: 
http://akahl.fedorapeople.org/php-ZendFramework/php-ZendFramework-1.6.0-0.1.rc1.fc9.src.rpm

Change:
- update to 1.6.0RC1
- added php-Fileinfo dependency


The Fileinfo/mime_magic issue is fixed now. SQLite support via PDO in
Zend_Cache_Backend_Sqlite is still missing (non-blocker). Also, we can
definitely go without the working unit tests for now but can we continue
collaboration on issues after the Fedora/RHEL release? Anyway, I'll open a Zend
Tracker account.

Gianluca: Ready for a review or do you want to wait for 1.6 final?

Talking about ZF issues still open, I'd love to see ZF-2151 fixed, maybe
utilizing libyaml/php-yaml.

Comment 41 Jess Portnoy 2008-07-29 08:31:52 UTC
Hi Alex and Gianluca,

About the unit tests, yes, of course you can count on our collaboration. I find
this issue to be very important and I was assured it will get proper
consideration in the future.

About 2151:
There is a PECL extension that can do the trick
[http://pecl.php.net/package-search.php?pkg_name=syck&bool=AND&submit=Search]
and also a nice article about how to utilize it
[http://devzone.zend.com/article/2585-using-yaml-with-php-and-pecl].
I will discuss this with the ZF guys and see how I can further promote it.
Things are a bit busy for me so I am not sure I commit to taking ownership and
writing this ZF component but we'll see :)
I urge you to open an account so we can collaborate in an even more affective
manner :)

P.S
Great work and thanks

Comment 42 Alexander Kahl 2008-07-30 11:18:23 UTC
Hi Jess,

thank you for your pledge.

About 2151:
I know all YAML alternatives for PHP pretty well and all of them have their
pitfalls, including syck; ATM syck-php segfaults for Fedora, at least on x86_64
and also i386 IIRC. spyc and Horde_Yaml are too slow because processing is done
via pure PHP code and while seeming mature, syck seems to be unmaintained (0.55
released 2005 May 18) and still sticks around with YAML 1.0; libyaml on the
other hand is considered alpha state despite being very stable (I'm using it for
production!), is under active development, offers YAML 1.1 support and has
php-yaml as third-party binding which is at least capable of deserialization
already; I've added a patch to get parser errors into PHP and sent it to the
original author but no reply so far. If necessary I'll add serialization support
myself.

Please consider the alternatives :)

Best regards

Comment 43 Jess Portnoy 2008-07-31 06:50:51 UTC
Hi Alex,

I will checkout the YAML issue. Maybe it's worth improving syck, making it
support YAML 1.1 and fix the seg fault[s]. I am not sure it is but it's worth
looking into. I will review the code first time I get.

Also, I run:
find /tmp/ZendFramework-1.6RC1/ -type f -perm /u+x,g+x

And discovered they still have the exec bit set for some files without cause, I
will open an issue about it and remind them once more.

Again, thanks for all the hard work. I think this process is very productive in
helping ZF become better.


Comment 44 Jess Portnoy 2008-07-31 15:02:04 UTC
Hi again,

I looked at PECL and saw the last update on the syck extension was issued on
2007-11-22 [version 0.9.2]. It's declared to be beta but that doesn't
necessarily mean anything. I compiled it and it loaded properly on my FC 8. Is
there a certain scenario that causes the seg fault? I am now interested :)

Comment 45 Gianluca Sforna 2008-08-01 07:44:43 UTC
Ok, I think it's time to get this into Fedora, let's see if I can carve some
time for the review

Comment 46 Alexander Kahl 2008-08-01 09:00:20 UTC
Hi Jess, hi Gianluca,

I'd really love to see syck back maintained and supporting YAML 1.1 or even 1.2
(http://code.google.com/p/yaml-cpp/ does it); as far as I can judge from the
alternatives' code basis, libyaml seems to be most suitable for extension as it
clearly follows formal grammar / parser theory patterns (BNF tokens etc.) but
maybe I'm just wrong here and underestimating syck.
Fedora's php-syck still seems to come from the original syck tarball instead of
php-pecl-syck, thus being utterly obsoleted. I'll file a bug report here right away.

Actually the file permissions issue is a classic amongst developers working in
heterogeneous environments as soon as the Redmond OS is involved. Btw. you can
also use -perm /111 to get u+x,g+x,o+x.

Hey, collaboration is what keeps the community alive and Free Software is what
makes us able to help our neighbor :)

Gianluca: Great! I know we're all busy and really appreciate your commitment here.

Comment 47 Gianluca Sforna 2008-08-01 23:40:04 UTC
==== REVIEW CHECKLIST ====
- package named according to package naming guidelines
- spec filename matches %{name}
- package meet packaging guidelines
- package licensed with open source compatible license (BSD)
- license matches actual license
- license file included in %doc
- spec written in American english
- spec legible
- source match upstream
196aef8904be20c199e536480f92c5c9  ./ZendFramework-1.6.0RC1.tar.gz
- successfully builds in mock for rawhide x86_64
- no locales
- no shared libraries
- package is not relocatable
- package owns all directories it creates
- file permissions set properly
- contains proper %clean
- macro usage is consistent
- package contains code
- no large documentation
- not a GUI app needing a .desktop file

- rpmlint output not clean

php-ZendFramework-Cache-Backend-Apc.noarch: W: no-documentation
php-ZendFramework-Cache-Backend-Memcached.noarch: W: no-documentation
php-ZendFramework-Cache-Backend-Memcached.noarch: W:
filename-too-long-for-joliet
php-ZendFramework-Cache-Backend-Memcached-1.6.0-0.1.rc1.fc9.noarch.rpm
php-ZendFramework-demos.noarch: W: no-documentation
php-ZendFramework-demos.noarch: E: htaccess-file
/usr/share/php/Zend/demos/OpenId/mvc_auth/html/.htaccess
php-ZendFramework-Feed.noarch: W: no-documentation
php-ZendFramework-Gdata.noarch: W: no-documentation
php-ZendFramework-Pdf.noarch: W: no-documentation
php-ZendFramework-Search-Lucene.noarch: W: no-documentation
php-ZendFramework-Services.noarch: W: no-documentation
php-ZendFramework-tests.noarch: W: no-documentation
php-ZendFramework-tests.noarch: E: zero-length
/usr/share/php/Zend/tests/Zend/Filter/_files/file.1
php-ZendFramework-tests.noarch: E: non-executable-script
/usr/share/php/Zend/tests/Zend/Text/Figlet/GenerateDummies.sh 0644
php-ZendFramework-tests.noarch: E: zero-length
/usr/share/php/Zend/tests/Zend/Text/Figlet/InvalidFont.flf
php-ZendFramework-tests.noarch: W: hidden-file-or-dir
/usr/share/php/Zend/tests/Zend/Auth/Adapter/Digest/_files/.htdigest.1
php-ZendFramework-tests.noarch: E: zero-length
/usr/share/php/Zend/tests/Zend/Soap/_files/cert_file
php-ZendFramework-tests.noarch: E: zero-length
/usr/share/php/Zend/tests/Zend/Http/Client/_files/testHeaders.php
php-ZendFramework-tests.noarch: W: file-not-in-%lang
/usr/share/php/Zend/tests/Zend/Translate/_files/test_fileerror.mo
php-ZendFramework-tests.noarch: W: file-not-in-%lang
/usr/share/php/Zend/tests/Zend/Translate/_files/testmsg_en.mo
php-ZendFramework-tests.noarch: W: file-not-in-%lang
/usr/share/php/Zend/tests/Zend/Translate/_files/testmsg_ru(koi8-r).mo
php-ZendFramework-tests.noarch: W: file-not-in-%lang
/usr/share/php/Zend/tests/Zend/Translate/_files/translate_bigendian.mo
10 packages and 0 specfiles checked; 6 errors, 15 warnings.


I think the "no-documentation" warnings could be ignored on subpackages. You may
consider adding the license file to silence it

filename-too-long-for-joliet is annoying if this is going to be burned on a
CD/DVD. I am not sure if that's a blocker

htaccess-file  IIRC htaccess files are ignored by the default apache
installation. please check if we can remove it without impacting the demo.

I think all the -tests W and E can be safely ignored. Please just double check
the .htdigest.1 and the zero lenght files are really the test targets.

One last remark. If there is some post installation steps the user is supposed
to do, please add a README.Fedora file with the appropriate note.

So, I can't see any blocker here, the package is APPROVED.

Comment 48 Alexander Kahl 2008-08-06 13:59:33 UTC
Gianluca:
I've fixed the "no-documentation" issue by adding the license to all subpackages. The joliet problem should go away with 1.6 stable; for the rest I've verified the files are necessary and correct for the unit tests. Right now there's nothing special required to have Zend Framework run on Fedora, if it ever will, I'll add a README.
Thanks again!

Jess:
Which way do you recommend for staying in contact, do you want to be set CC for Zend Framework related bugs in RedHat Bugzilla or should I open a Zend Jira account and forward bug reports where applicable?


Sorry guys for taking so long but whenever I tried posting Bugzilla's update seemed to get into my way..

Comment 49 Alexander Kahl 2008-08-06 14:11:22 UTC
New Package CVS Request
=======================
Package Name:      php-ZendFramework
Short Description: Leading open-source PHP framework
Owners:            akahl
Branches:          F-9
InitialCC: 
Cvsextras Commits: yes

Comment 50 Jess Portnoy 2008-08-06 14:22:12 UTC
Hi Alex,

I'd love to be set CC. It can't hurt :)

Comment 51 Kevin Fenzi 2008-08-06 17:40:08 UTC
cvs done.

Comment 52 Alexander Kahl 2008-08-07 09:49:45 UTC
All builds successful. If anyone wants this into EPEL/RHEL, I'll consider it - but for now, the implicated long-term responsibility is quite daunting.

Thank you Jess and Gianluca for your help!

Comment 53 Jess Portnoy 2008-08-10 08:05:39 UTC
Hi Alex,

I was thinking, it might be a good idea for the RPM %post to run the following:

sed 's@\(^include_path\s*=\s*".*\)"@\1:%{_datadir}/php"@' -i /etc/php.ini

So that the prefix for ZF is found within PHP's include path.
I don't think it's a must and can also think of reasons why not to interfere with the php.ini but still, thought I'd suggest it none the less.

Comment 54 Alexander Kahl 2008-08-10 10:43:39 UTC
Hi Jess,

nice idea but actually useless for Fedora:
include_path is not set in php.ini by default, instead it's hard-coded by a patch to
.:/usr/share/pear:/usr/share/php
(in C: INCLUDE_PATH=.:$EXPANDED_PEAR_INSTALLDIR:${EXPANDED_DATADIR}/php)

Our policy is to install PEAR packages into /usr/share/pear and all other PHP packages into /usr/share/php; if anyone wishes to override the path, he or she has to make sure the default still applies.

Comment 55 Jess Portnoy 2008-08-10 16:19:54 UTC
OK, I would love to hear to reason for this patch someday but it seems in that case it is indeed useless :)

Comment 56 Felix Kaechele 2011-07-09 20:59:08 UTC
Package Change Request
======================
Package Name: php-ZendFramework
New Branches: el5 el6
Owners: heffer

Comment 57 Felix Kaechele 2011-07-09 21:02:43 UTC
Ah, sorry. Drop the el5. PHP in EL5 is too old for ZendFramework.

Comment 58 Gwyn Ciesla 2011-07-09 23:42:39 UTC
Git done (by process-git-requests).

EL-5 dropped.

Comment 59 Gianluca Sforna 2011-07-10 21:49:26 UTC
For the records, RHEL 5.6 got a php53 package which I guess is possible to use as a dep for the EL-5 branch

Comment 60 Felix Kaechele 2014-10-10 20:32:31 UTC
Package Change Request
======================
Package Name: php-ZendFramework
New Branches: el7
Owners: heffer

Comment 61 Kevin Fenzi 2014-10-13 22:57:57 UTC
Git done (by process-git-requests).


Note You need to log in before you can comment on or make changes to this bug.