Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:102447 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 51910 invoked from network); 25 Jun 2018 23:14:40 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 25 Jun 2018 23:14:40 -0000 Authentication-Results: pb1.pair.com header.from=alice@librelamp.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=alice@librelamp.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain librelamp.com designates 45.79.96.192 as permitted sender) X-PHP-List-Original-Sender: alice@librelamp.com X-Host-Fingerprint: 45.79.96.192 librelamp.com Received: from [45.79.96.192] ([45.79.96.192:59354] helo=librelamp.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 39/10-50433-F57713B5 for ; Mon, 25 Jun 2018 19:14:40 -0400 Received: from localhost.localdomain (unknown [IPv6:2600:1010:b008:b4ae:7439:cd98:ad3:ac71]) by librelamp.com (Postfix) with ESMTPSA id 389824AD for ; Mon, 25 Jun 2018 23:14:37 +0000 (UTC) To: internals@lists.php.net References: <1529936020.4441.10.camel@schlueters.de> Message-ID: Date: Mon, 25 Jun 2018 16:14:36 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <1529936020.4441.10.camel@schlueters.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [PHP-DEV] PHP 2^3 From: alice@librelamp.com (Alice Wonder) On 06/25/2018 07:13 AM, Johannes Schlüter wrote: > On Mo, 2018-06-25 at 12:30 +0000, Zeev Suraski wrote: >> 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 > 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)