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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
