Re: Bundling third-party libraries
| From: | Lukas Smith | Date: | Mon, 05 Jun 2006 14:56:57 +0000 |
| Subject: | Re: Bundling third-party libraries | ||
| References: | 1 2 3 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-42770@lists.php.net to get a copy of this message | ||
Greg Beaver wrote:
The reason is that people who do third-party distros like unix/linux distros will not necessarily take the time to determine what is actually needed. In addition, suddenly having to download from a site other than pear.php.net to create the bundles may be very confusing and make them scared.Well I dont think it needs to be a legal document. I think the maintainer can take care of that, along with a note in the package description. Also we might mandate dependencies on specific versions?
Well I think thats a bumpy reason. Definately sounds quite solveable. Then again we way E_STRICT is starting to look is that it will make code impossible across major versions, since new major versions will almost always deprecate some thing. So once PHP6 is here we have no choice but to port every package to PHP6 asap. But we do not need to do this for PHP5 yet. So I do not see a point in hurrying E_STRICT releases for PHP5. But this is getting into questions of long terms planning that we have not succeeded at all in the entire time since PHP5 was released. So maybe we cannot put too much thought into the future and make every decision like there is no tomorrow.- we require proof that no PEAR package could provide the required functionality with reasonable effortThis is generally the case, but I think it is patently obvious that there is no E_STRICT console-based application in PEAR.
Well, like I said we I do not think we need to setup some legal relation. I think a simple but explicit trust relation on some higher level than just a single maintainer is sufficient.- we setup some guidelines about how to decide on a case by case basisI would prefer to discuss each case independently until we have an explicit legal sanctioning of external channels.
As for Sebastian's query, in my opinion, as long as the license is valid (and it is), then just bundle it directly in CVS. phpDocumentor has been bundling dependencies internally since forever, and there's never been a problem. If the channel gets sanctioned, you can remove the code from CVS and add a dependency instead.Which packages are these? I only thought Smarty is bundled, which is after all a php.net project. I also noticed that there is HTML_TreeMenu in the CVS. Is this still necessary even? regards, Lukas