Re: PHP 2^3
| From: | Alice Wonder | Date: | Mon, 25 Jun 2018 23:14:36 +0000 |
| Subject: | Re: PHP 2^3 | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-102447@lists.php.net to get a copy of this message | ||
On 06/25/2018 07:13 AM, Johannes Schlüter wrote:
On Mo, 2018-06-25 at 12:30 +0000, Zeev Suraski wrote:As a packager github is a fracking nightmare. Frequently what we do is include a hash of the release tarball in our build and require that it matches so that people rebuilding our package (e.g. to add a patch they need) don't have to trust us, they can use our build spec file but fetch the upstream source themselves, and the hash matches lets them know that what they fetched from upstream is identical to what the initial packager used. But with github getting the url to the actual download is tricky and often breaks and also I've seen the hash from the release tarball on github differ from the hash the release tarball on the project site numerous times. git is for code management but when a release it tagged, creation of the source tarball should be done by the developer, and released by the developer, preferably with sha256 or sha512 sums posted in an easy to find location (which github doesn't do)3. Foreign Function Interface support.Related to this on a non-PHP-code and strategic matter I would like to rethink PECL. Currently maintenance and installing extensions using it is a pita. This should be doable in a nicer way. (i.e. pecl pointing directly to Git(Hub) repos, similar to composer, a way to install precompiled binaries, probably using a more narrow stable API, better reporting of dependency issues, with the new execution model of your point 2 also better integration with composer, ...) johannes