pkgsrc-Users archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Switching default version of PHP/RUBY and retirement...
Thomas Klausner <wiz%gatalith.at@localhost> writes:
> On Fri, Feb 02, 2024 at 01:27:43PM +0000, Stephen Borrill wrote:
>> I want to see php56 kept (and probably php74), certainly until the time that
>> it is unable to build and fixing it is too much work.
>
> This is probably a pet peeve of mine and this is not intended to
> target Stephen, but
>
> - there is no reason given why it should be kept
that's fair
> - there is no offer to maintain it, just asking other to do work
>
> Please consider time others have to spend if you request stuff like
> this...
Is the continued existence of php56 causing anyone work? That theory is
part of the justification, but I haven't seen anyone even claim it, let
alone explain. I've been reading pkgsrc-changes for years and I'm just
not seeing it (in this case).
As for why, there are at least some packages in pkgsrc that work with
php56 and not with newer. Nobody (who would like to rm -rf php56,
thereby also removing those packges that require it) has provided a list
of those packages, so we can think about the total loss vs the reduction
in effort.
I don't mean the above to prejudge the balancing of concerns. Just that
we should have an idea of maintenence burden and usage rather than
assuming.
There are 19 packages marked PHP_VERSIONS_INCOMPATIBLE=56, and another 4
that are incompatible with both 56 and also at least one higher
version. So presumably any packages updated to versions that drop 56
might have to add line, and this is the burden.
There are 36 marked PHP_VERSIONS_ACCEPTED with only 56.
There are 16 that have PHP_VERSIONS_ACCEPTED with 56 and some higher
version. Some of that is "not 83", but a fair bit is 56/74 only.
There are 26 that have PHP_VERSIONS_ACCEPTED not including 56, and of
those only 5 are ok with php83.
So removing php56 would lose at least the ones that only ACCEPT 56:
./audio/ampache/Makefile:PHP_VERSIONS_ACCEPTED= 56
./converters/php-recode/Makefile:PHP_VERSIONS_ACCEPTED= 56
./databases/pear-MDB2_Driver_mysql/Makefile:PHP_VERSIONS_ACCEPTED= 56
./databases/php-dbx/Makefile:PHP_VERSIONS_ACCEPTED= 56
./databases/php-mongo/Makefile:PHP_VERSIONS_ACCEPTED= 56
./databases/php-mssql/Makefile:PHP_VERSIONS_ACCEPTED= 56
./databases/php-mysql/Makefile:PHP_VERSIONS_ACCEPTED= 56
./databases/php-redis4/Makefile:PHP_VERSIONS_ACCEPTED= 56
./databases/php-rrd/Makefile:PHP_VERSIONS_ACCEPTED= 56
./devel/php-memcache2/Makefile:PHP_VERSIONS_ACCEPTED= 56
./devel/php-memcached/Makefile:PHP_VERSIONS_ACCEPTED= 56
./devel/php-pthreads/Makefile:PHP_VERSIONS_ACCEPTED= 56
./devel/php-raphf/Makefile:PHP_VERSIONS_ACCEPTED= 56
./devel/php-xcache/Makefile:PHP_VERSIONS_ACCEPTED= 56
./finance/magento/Makefile:PHP_VERSIONS_ACCEPTED= 56
./lang/php56/Makefile:PHP_VERSIONS_ACCEPTED= 56
./mail/imp/Makefile:PHP_VERSIONS_ACCEPTED= 56
./mail/ingo/Makefile:PHP_VERSIONS_ACCEPTED= 56
./mail/mimp/Makefile:PHP_VERSIONS_ACCEPTED= 56
./security/php-mcrypt/Makefile:PHP_VERSIONS_ACCEPTED= 56
./security/php-oauth1/Makefile:PHP_VERSIONS_ACCEPTED= 56
./security/php-ssh2-0/Makefile:PHP_VERSIONS_ACCEPTED= 56
./security/php-suhosin/Makefile:PHP_VERSIONS_ACCEPTED= 56
./textproc/php-sphinx/Makefile:PHP_VERSIONS_ACCEPTED= 56
./textproc/php-wddx/Makefile:PHP_VERSIONS_ACCEPTED= 56
./time/kronolith/Makefile:PHP_VERSIONS_ACCEPTED= 56
./www/blur6ex/Makefile:PHP_VERSIONS_ACCEPTED= 56
./www/gallery2/Makefile:PHP_VERSIONS_ACCEPTED= 56
./www/matcha-sns/Makefile:PHP_VERSIONS_ACCEPTED= 56
./www/php-apcu4/Makefile:PHP_VERSIONS_ACCEPTED= 56
./www/php-concrete5/Makefile:PHP_VERSIONS_ACCEPTED= 56
./www/php-phalcon/Makefile:PHP_VERSIONS_ACCEPTED= 56
./www/php-phrasea2/Makefile:PHP_VERSIONS_ACCEPTED= 56
./www/php-propro/Makefile:PHP_VERSIONS_ACCEPTED= 56
./www/phraseanet/Makefile:PHP_VERSIONS_ACCEPTED= 56
./www/typo3_62/Makefile:PHP_VERSIONS_ACCEPTED= 56
A lot of this may be cruft. It seems unlikely that it is all useless.
Looking at lang/php56/Makefile and ignoring "revbump for foo", I find
two fixes presumably inspired by later php and applied, and that's it,
before I reach an update from when php56 was *not* EOL just over 4 years
ago. This doesn't seem like a lot of work.
revision 1.30
date: 2022-10-30 06:50:01 -0400; author: taca; state: Exp; lines: +5 -5; commitid: 1bTK4YadAZO6nJZD;
lang/php: post-install clean up
Do not manually install executable files and manual.
These are already done by php's Makefile from some time ago.
revision 1.22
date: 2019-05-23 15:23:03 -0400; author: rillig; state: Exp; lines: +3 -3; commitid: aWlQW8HYUUFCAmoB;
all: replace SUBST_SED with the simpler SUBST_VARS
pkglint -Wall -r --only "substitution command" -F
With manual review and indentation fixes since pkglint doesn't get that
part correct in every case.
and then an update from when it wasn't EOL:
revision 1.20
date: 2019-01-12 10:01:34 -0500; author: taca; state: Exp; lines: +1 -2; commitid: NDecAuzqM7ekmv7B;
lang/php56: udate to 5.6.40
10 Jan 2019, PHP 5.6.40
- GD:
. Fixed bug #77269 (efree() on uninitialized Heap data in imagescale leads to
use-after-free). (cmb)
. Fixed bug #77270 (imagecolormatch Out Of Bounds Write on Heap). (cmb)
- Mbstring:
. Fixed bug #77370 (Buffer overflow on mb regex functions - fetch_token). (Stas)
. Fixed bug #77371 (heap buffer overflow in mb regex functions
- compile_string_node). (Stas)
. Fixed bug #77381 (heap buffer overflow in multibyte match_at). (Stas)
. Fixed bug #77382 (heap buffer overflow due to incorrect length in
expand_case_fold_string). (Stas)
. Fixed bug #77385 (buffer overflow in fetch_token). (Stas)
. Fixed bug #77394 (Buffer overflow in multibyte case folding - unicode). (Stas)
. Fixed bug #77418 (Heap overflow in utf32be_mbc_to_code). (Stas)
- Phar:
. Fixed bug #77247 (heap buffer overflow in phar_detect_phar_fname_ext). (Stas)
- Xmlrpc:
. Fixed bug #77242 (heap out of bounds read in xmlrpc_decode()). (cmb)
. Fixed bug #77380 (Global out of bounds read in xmlrpc base64 code). (Stas)
Home |
Main Index |
Thread Index |
Old Index