Skip to content
This repository has been archived by the owner on Jan 2, 2019. It is now read-only.

Question: Why forked OLE instead of PEAR's OLE? #407

Open
siwinski opened this issue Jul 21, 2014 · 3 comments
Open

Question: Why forked OLE instead of PEAR's OLE? #407

siwinski opened this issue Jul 21, 2014 · 3 comments

Comments

@siwinski
Copy link

Why is this library using a fork of OLE (Classes/PHPExcel/Shared/OLE*) instead of PEAR's OLE? I am asking because I am trying to package this library for Fedora/EPEL but in order to do that I must unbundle all bundled libraries. I have been asked why PEAR'S OLE is not being used and I do not have a good answer. It appears this library's OLE is much older than PEAR's OLE.

@MarkBaker
Copy link
Member

There are a number of changes and bugfixes to the OLE container here that aren't implemented in the PEAR OLE (e.g. Work items 10252 and 15308 from the old Codeplex issues log). It was originally bundled with PHPExcel for the benefit of people who couldn't/wouldn't install dependencies manually; and last updated from PEAR for the PHPExcel 1.5.0 release on 32rd October 2007. It has also been modified to use class constants rather then global constants, work with the PHPExcel autoloader, and throw PHPExcel errors rather than PEAR errors, mainly to provide consistency with the rest of PHPExcel.

If you look at the changelog for PEAR OLE, there have only been 2 subsequent releases since the bundled version (OLE-1.0.0RC1 from May 2008, with a bugfix for Incompatibility open_basedir restriction; and then a 4-year gap till 1.0.0RC2 with a couple of bugfixes for Invalid Bigblock chain with files > 200MB and OLE doesn't save multistreams).

While the PHPExcel fork should probably be modified to reflect those additional bugfixes, it seems awkward to unbundle the OLE again, making it difficult to use composer, giving problems with inconsistent error handling between PHPExcel and PEAR, and giving us a dependency on an unsupported library once more.

@flack
Copy link

flack commented Sep 3, 2014

@MarkBaker just FYI: PEAR components have been available on composer & gibthub for a while now:

https://github.com/pear/OLE

I don't know how maintained they are, but it might be worth a try to send them a PR with some of your changes and see what happens

@siwinski
Copy link
Author

siwinski commented Jul 3, 2015

Upstream has this text @ http://pear.php.net/package/OLE :

This package is not maintained, if you would like to take over please go to this page.

I'm not a license expert, but can all the OLE files (that were originally taken from the PEAR OLE project and modified for this library) have their license headers changed to match the rest of this library's license? This would make the fork of the PEAR OLE package apparent and should bypass the "no bundled libraries" I need to conform to downstream when trying to package for Fedora/EPEL.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants