Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:47795 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 84415 invoked from network); 5 Apr 2010 18:10:54 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 5 Apr 2010 18:10:54 -0000 X-Host-Fingerprint: 200.52.223.158 unknown Received: from [200.52.223.158] ([200.52.223.158:17988] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id D5/B3-60700-DA72ABB4 for ; Mon, 05 Apr 2010 14:10:54 -0400 Message-ID: To: internals@lists.php.net Followup-To: php.internals Lines: 94 Date: Mon, 05 Apr 2010 13:11:05 -0500 References: <1263654424.3127.43.camel@guybrush> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8Bit X-Posted-By: 200.52.223.158 Subject: Re: Re: [PHP-DEV] Debian PHP patches From: geissert@php.net (Raphael Geissert) Raphael Geissert wrote: > Johannes Schlüter wrote: > > Although I would have preferred you wait for me to submit each patch > individually with enough information (because I've only been like two > years co-maintaining the packages and most patches were added by others, > and most before I joined), thanks. I'll try to comment on each but I don't > know about them all and can't check them right now (I'm short on time). > I haven't had much time to work on merging those patches, but will try to eventually get to do it. >> 047-zts_with_dl.patch >> I don't support this. dl() can be used by CLI users for loading Gtk or >> such on demand but avoiding to load (and inititalize) all the Gtk >> stuff every time they use PHP and avoid messing with config files... The least I can say is that that patch is obsolete. We don't build the apache modules with ZTS. However, I don't understand what you are saying about Gtk. The patch doesn't change the behaviour of the cli/cgi/embed SAPIs. It only re-enables dl() on any SAPI even with ZTS. >> 052-phpinfo_no_configure.patch >> Neither do I support this. Users might benefit when building own >> modules or might be interested in the configure line for other >> reasons ... The main issue is that we build the different SAPIs with different configure flags. This seems to have lead to bogus bug reports in the past and confusion (--disable-*/--without-* in certain SAPIs). For example, the shared extensions are built when building the apache SAPI, the cgi build options are also massaged after a first build, etc. >> >> 053-extension_api.patch >> When adding random options to command line tools please mark them as >> Debian specific. Additionally the man page should be updated. > > Indeed. In this case I'd prefer if this option is added upstream. > The --phpapi option is used to determine the path to the extensions > directory. In the case of architectures where LFS is enabled, the phpapi > value is appended '+lfs'. Is there any objection to making this change? (only to trunk, I assume.) >> 100-recode_is_shared.patch >> The conflict between MySQL and recode should only happen with an old >> libmysql (3.23?) not sure about imap ... but in your case the patch >> might make sense, while I won't directly apply it to our tree as >> usually people will build extensions to load them together... Shouldn't checking for $PHP_IMAP_SHARED != "yes" (and the same for mysql) work? if either recode or imap/mysql are being built as shared I don't think there's any reason to abort the build. A warning should be enough, don't you think? >> 108-64_bit_datetime.patch >> 116-posixness_fix.patch >> Why is that needed on our system? - I never saw an issue about these >> and if they are missing there should be build issues. > > I will later be commenting on these two. Haven't had time to check, deferring. >> Did you consider mysqlnd? Leaving any security concern aside, there are at the moment some missing features and behaviour changes that I don't feel very comfortable with. In a future release we might switch, but won't happen for Squeeze. > Some of the other patches include: > libdb_is_-ldb Not yet merged, but at least support for db-4.{7,8} was added. > 115-autoconf_ftbfs.patch as per discussion we will continue carrying it > fix_broken_upstream_tests.patch not completely merged/resolved > bad_whatis_entries.patch merged Cheers, -- Raphael Geissert