Welcome! Log In Create A New Profile

Advanced

[PHP-DEV] [RFC] [VOTE] Cleaning up unmaintained extensions

Posted by Stanislav Malyshev 
Stanislav Malyshev
[PHP-DEV] [RFC] [VOTE] Cleaning up unmaintained extensions
June 17, 2018 09:50PM
Hi!

I would like to open the vote for the RFC about cleaning up the
unmaintained extensions:

https://wiki.php.net/rfc/umaintained_extensions

The vote ends 2018-06-26 23:59 PDT.

I have added some discussion about active maintainers and abandonment
procedures, this can be refined further later. I also kept the list of
the candidates as-is for now, but I will update it soon and probably
make a separate wiki page for maintaining it. Please note this list is
not part of the vote (the vote is on the process, not specific list
which will change all the time).

Thanks,
--
Stas Malyshev
smalyshev@gmail.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Christopher Jones
Re: [PHP-DEV] [RFC] [VOTE] Cleaning up unmaintained extensions
June 18, 2018 05:20AM
On 18/6/18 5:43 am, Stanislav Malyshev wrote:
> Hi!
>
> I would like to open the vote for the RFC about cleaning up the
> unmaintained extensions:
>
> https://wiki.php.net/rfc/umaintained_extensions
>
> The vote ends 2018-06-26 23:59 PDT.
>
> I have added some discussion about active maintainers and abandonment
> procedures, this can be refined further later. I also kept the list of
> the candidates as-is for now, but I will update it soon and probably
> make a separate wiki page for maintaining it. Please note this list is
> not part of the vote (the vote is on the process, not specific list
> which will change all the time).
>
> Thanks,
- I know we're all online all the time, but I would have gone for a 4 week period instead of 3.  Many countries have significant vacation periods.

- the "community maintained" option looks OK.

- Since this is a process & policy RFC that has a long lifespan as a reference, what about renaming it to 'PHP RFC: Process for Unmaintained Extensions'?

[Somehow https://wiki.php.net/rfc should capture these active references. Currently they are in the same section as things such as PHP 5.3 EOL]

Chris

--
http://twitter.com/ghrd
On 17 June 2018 at 20:43, Stanislav Malyshev <[email protected]> wrote:

> Hi!
>
> I would like to open the vote for the RFC about cleaning up the
> unmaintained extensions:
>
> https://wiki.php.net/rfc/umaintained_ejkxtensions
> https://wiki.php.net/rfc/umaintained_extensions
>
> The vote ends 2018-06-26 23:59 PDT.
>
> I have added some discussion about active maintainers and abandonment
> procedures, this can be refined further later. I also kept the list of
> the candidates as-is for now, but I will update it soon and probably
> make a separate wiki page for maintaining it. Please note this list is
> not part of the vote (the vote is on the process, not specific list
> which will change all the time).
>

Can anyone point me at the discussion thread for the revival of this RFC?
On the mailing list there have been a small number of mails broadly about
extensions and maintainers, and it looks like the RFC was only edited a few
days ago, but I feel like a dummy and can't find the "I'd like to revive
this RFC" thread at all.


>
> Thanks,
> --
> Stas Malyshev
> smalyshev@gmail.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
On Sun, Jun 17, 2018 at 3:43 PM, Stanislav Malyshev <[email protected]> wrote:
> I would like to open the vote for the RFC about cleaning up the
> unmaintained extensions:
>
> https://wiki.php.net/rfc/umaintained_extensions
>
> The vote ends 2018-06-26 23:59 PDT.
>
> I have added some discussion about active maintainers and abandonment
> procedures, this can be refined further later. I also kept the list of
> the candidates as-is for now, but I will update it soon and probably
> make a separate wiki page for maintaining it. Please note this list is
> not part of the vote (the vote is on the process, not specific list
> which will change all the time).
>
FTR; My yes vote comes with the endorsement that I'd like to see us
followup on that future scope work to make this into an on-going
policy rather than focus on the specific extensions in this moment.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Christoph M. Becker
Re: [PHP-DEV] [RFC] [VOTE] Cleaning up unmaintained extensions
June 18, 2018 05:10PM
On 18.06.2018 at 14:23, Peter Cowburn wrote:

> On 17 June 2018 at 20:43, Stanislav Malyshev <[email protected]> wrote:
>
>> I would like to open the vote for the RFC about cleaning up the
>> unmaintained extensions:
>>
>> https://wiki.php.net/rfc/umaintained_ejkxtensions
>> https://wiki.php.net/rfc/umaintained_extensions
>>
>> The vote ends 2018-06-26 23:59 PDT.
>>
>> I have added some discussion about active maintainers and abandonment
>> procedures, this can be refined further later. I also kept the list of
>> the candidates as-is for now, but I will update it soon and probably
>> make a separate wiki page for maintaining it. Please note this list is
>> not part of the vote (the vote is on the process, not specific list
>> which will change all the time).
>
> Can anyone point me at the discussion thread for the revival of this RFC?
> On the mailing list there have been a small number of mails broadly about
> extensions and maintainers, and it looks like the RFC was only edited a few
> days ago, but I feel like a dummy and can't find the "I'd like to revive
> this RFC" thread at all.

I had not opened a new thread, but rather replied to the original
discussion thread in <https://externals.io/message/95172#102234>;.

--
Christoph M. Becker

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Mon, Jun 18, 2018 at 4:43 AM, Stanislav Malyshev <[email protected]>
wrote:

> Hi!
>
> I would like to open the vote for the RFC about cleaning up the
> unmaintained extensions:
>
> https://wiki.php.net/rfc/umaintained_extensions
>
> The vote ends 2018-06-26 23:59 PDT.
>

Just to be sure consequence of "readline" removal.

With CLI, "php -a" and "history" works without readline?
Does it work as dynamically loaded module?

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net
Stanislav Malyshev
Re: [PHP-DEV] [RFC] [VOTE] Cleaning up unmaintained extensions
June 19, 2018 09:50PM
Hi!

> Hi!
>
> I would like to open the vote for the RFC about cleaning up the
> unmaintained extensions:
>
> https://wiki.php.net/rfc/umaintained_extensions
> https://wiki.php.net/rfc/umaintained_extensions
>
> The vote ends 2018-06-26 23:59 PDT.
>
>
> Just to be sure consequence of "readline" removal.
>
> With CLI, "php -a" and "history" works without readline?
> Does it work as dynamically loaded module?

CLI can still use readline library. This would be about readline PHP
extension.

--
Stas Malyshev
smalyshev@gmail.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Sun, Jun 17, 2018 at 9:43 PM, Stanislav Malyshev <[email protected]>
wrote:

> Hi!
>
> I would like to open the vote for the RFC about cleaning up the
> unmaintained extensions:
>
> https://wiki.php.net/rfc/umaintained_extensions
>
> The vote ends 2018-06-26 23:59 PDT.
>
> I have added some discussion about active maintainers and abandonment
> procedures, this can be refined further later. I also kept the list of
> the candidates as-is for now, but I will update it soon and probably
> make a separate wiki page for maintaining it. Please note this list is
> not part of the vote (the vote is on the process, not specific list
> which will change all the time).
>

I really don't like this.

There are two extensions that I'm aware of where we have strong technical
grounds to remove them, that's wddx (for reasons of security and
questionable utility) and interbase (has a major bug since the PHP 7
migration and there is nobody with knowledge of this exotic DB driver to
fix it).

If we have technical grounds for a removal and nobody is willing to step up
to resolve the issues, then I'm all for moving extensions to PECL. If this
is not the case, then I feel that removing them will not make the situation
any better (especially seeing relatively common extensions like gettext,
readline and ftp on that list). Extensions without official maintainer in
php-src tend to be passively maintained, e.g. I remember merging various
PRs to the ftp extension over the last few years (and of course, small
extensions like gettext just don't get many changes over time). Moving an
extension to PECL effectively makes it completely unmaintained.

To me, moving extensions to PECL is a Pretty Big Deal. It's something that
should be done on a case-by-case basis, possibly with an RFC, not something
that happens based on a blanket policy.

Regards.
Nikita
On 19/06/18 21:20, Nikita Popov wrote:
> and interbase (has a major bug since the PHP 7
> migration and there is nobody with knowledge of this exotic DB driver to
> fix it).

What Bug!
It's passing all the test that I run on it perfectly stably otherwise I
would not even bother with PHP7. But the problem supporting ANY driver
is the exotic nature of PHP is just as difficult as the tools it needs
to interface with to make a fully functional stack ...

--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Stanislav Malyshev
Re: [PHP-DEV] [RFC] [VOTE] Cleaning up unmaintained extensions
June 19, 2018 10:50PM
Hi!

> There are two extensions that I'm aware of where we have strong
> technical grounds to remove them, that's wddx (for reasons of security
> and questionable utility) and interbase (has a major bug since the PHP 7
> migration and there is nobody with knowledge of this exotic DB driver to
> fix it).

I mostly agree, but this RFC is not for discussing specific extensions,
it's for establishing the policy of what we do with such extensions, and
how.

> like gettext, readline and ftp on that list). Extensions without
> official maintainer in php-src tend to be passively maintained, e.g. I

Or not. As is the case with several of them.

> years (and of course, small extensions like gettext just don't get many
> changes over time). Moving an extension to PECL effectively makes it
> completely unmaintained.

I think if it doesn't have official maintainer and nobody touched it for
years, it's completely unmaintained right now. But for cases like this,
the RFC says:

Option: for some extensions, which are clearly needed but nobody stepped
up in person to claim maintainership, we can have designated “community
maintained” status, which would mean PHP developers as a group have
shared responsibility for this extension.

>
> To me, moving extensions to PECL is a Pretty Big Deal. It's something
> that should be done on a case-by-case basis, possibly with an RFC, not
> something that happens based on a blanket policy.

I do not see any contradiction between this and what RFC says. In fact,
RFC specifically says:

In case there are objections to moving unmaintained extension to PECL,
separate RFC vote can be held about the move, initiated by the RMs of
the current release or any interested party. The decision can be taken
for each extension individually.

So what exactly you don't like here? It's pretty much exactly the
opposite of "blanket policy".

I am sorry if I am missing something, but it looks to me like you're
saying "I don't like this, we should do this instead" and then literally
you are saying exactly what the RFC is saying. Where is the problem?

--
Stas Malyshev
smalyshev@gmail.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Stanislav Malyshev
Re: [PHP-DEV] [RFC] [VOTE] Cleaning up unmaintained extensions
June 19, 2018 10:50PM
Hi!

> What Bug!
> It's passing all the test that I run on it perfectly stably otherwise I
> would not even bother with PHP7. But the problem supporting ANY driver
> is the exotic nature of PHP is just as difficult as the tools it needs
> to interface with to make a fully functional stack ...

I have four bugs for interbase and four for firebird submitted just
recently, as security issues. Do you want to take care of them? I can
assign them to you if you want to take care of them.

Thanks,
--
Stas Malyshev
smalyshev@gmail.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 19/06/18 21:48, Stanislav Malyshev wrote:
>> What Bug!
>> It's passing all the test that I run on it perfectly stably otherwise I
>> would not even bother with PHP7. But the problem supporting ANY driver
>> is the exotic nature of PHP is just as difficult as the tools it needs
>> to interface with to make a fully functional stack ...
> I have four bugs for interbase and four for firebird submitted just
> recently, as security issues. Do you want to take care of them? I can
> assign them to you if you want to take care of them.

The last time I managed to patch php was over 15 years ago, I have not
been able to get a handle on the new structure used by PHP7 in part
because I've not had time to do any C coding since. I'm still working on
moving PHP5.2 code to work on PHP7 while keeping the stack working on
W10 and maintained versions of SUSE Linux. And some of the stuff I
thought I'd finished upgrading is not working again :(

I'm not seeing any bugs listed in bugs.php.net that are security risks.
I don't touch PDO_firebird as it does not handle key Firebird features
so looking at 'InterBase related' only returns 8 bugs, and one of them
is missing documentation on the fbird_ aliases that I use in the ADOdb
Firebird driver. THAT is something I do spend time keeping tidy, and
fixes some of the niggles raw access encounters, but I will have a look
at the 2017 bugs that I'd not been aware of ... the other bugs are
somewhat exotic but not security matters.

--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Stanislav Malyshev
Re: [PHP-DEV] Cleaning up unmaintained extensions - interbase
June 20, 2018 07:10AM
Hi!

> The last time I managed to patch php was over 15 years ago, I have not
> been able to get a handle on the new structure used by PHP7 in part
> because I've not had time to do any C coding since. I'm still working on
> moving PHP5.2 code to work on PHP7 while keeping the stack working on
> W10 and maintained versions of SUSE Linux. And some of the stuff I
> thought I'd finished upgrading is not working again :(

php7 builds are not that different from php5 builds, and I suspect the
issues discovered are also present in earlier versions.

> I'm not seeing any bugs listed in bugs.php.net that are security risks.

Security issues are not publicly visible. If you have php account, I
could assign them to you and you could see them. Or I could arrange a
copy for you, if you intend to work on them.

Thanks,
--
Stas Malyshev
smalyshev@gmail.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 20/06/18 06:04, Stanislav Malyshev wrote:
> php7 builds are not that different from php5 builds, and I suspect the
> issues discovered are also present in earlier versions.

Marius has had more luck understanding the nuances of changes and
massaging my previous attempts in with his fixes, but I don't think
either of us are totally comfortable with the C end of things! Things
have changed somewhat in the 40 years since I got my MSc in 'Digital
Systems' and today even PHP is black magic at times :(

>> I'm not seeing any bugs listed in bugs.php.net that are security risks.
> Security issues are not publicly visible. If you have php account, I
> could assign them to you and you could see them. Or I could arrange a
> copy for you, if you intend to work on them.

Current builds of Interbase and Firebird are moving further apart and
security is one area affected. It may well be that we need to split out
the Firebird aliases and current builds of Firebird 3 have different
security layers to FB2.x and Interbase now. I would at least like to see
a copy of what we are talking about and see if I have any chance of
being able to work on them ...

You consider Firebird a niche area, and similarly the Firebird
developers consider PHP the same as the main application software is
Delphi and C/C++ so trying to get help from either end has always been a
battle. But for me it is still a much more reliable base than MySQL yet
new users have little option but to live with second grade tools.

I'm not sure just what accounts I have on PHP these days. I used to have
logins but I forget nowadays what for. I would just like to get back to
producing content rather than firefighting changes every day ...

--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Tue, Jun 19, 2018 at 11:47 PM, Lester Caine <[email protected]> wrote:

> On 19/06/18 21:48, Stanislav Malyshev wrote:
>
>> What Bug!
>>> It's passing all the test that I run on it perfectly stably otherwise I
>>> would not even bother with PHP7. But the problem supporting ANY driver
>>> is the exotic nature of PHP is just as difficult as the tools it needs
>>> to interface with to make a fully functional stack ...
>>>
>> I have four bugs for interbase and four for firebird submitted just
>> recently, as security issues. Do you want to take care of them? I can
>> assign them to you if you want to take care of them.
>>
>
> The last time I managed to patch php was over 15 years ago, I have not
> been able to get a handle on the new structure used by PHP7 in part because
> I've not had time to do any C coding since. I'm still working on moving
> PHP5.2 code to work on PHP7 while keeping the stack working on W10 and
> maintained versions of SUSE Linux. And some of the stuff I thought I'd
> finished upgrading is not working again :(
>
> I'm not seeing any bugs listed in bugs.php.net that are security risks. I
> don't touch PDO_firebird as it does not handle key Firebird features so
> looking at 'InterBase related' only returns 8 bugs, and one of them is
> missing documentation on the fbird_ aliases that I use in the ADOdb
> Firebird driver. THAT is something I do spend time keeping tidy, and fixes
> some of the niggles raw access encounters, but I will have a look at the
> 2017 bugs that I'd not been aware of ... the other bugs are somewhat exotic
> but not security matters.


Just to clarify which bug I was referring to in that mail, it's this one:
https://bugs.php.net/bug.php?id=72175

There are three issues that must be addressed:
* The issue in the original bug report: Connecting to the same DB multiple
times does not work.
* The use of zend_list_delete() in *_close() functions, which is
memory-unsafe.
* Incorrect interaction of closing and multiple shared connections. While
the underlying connection is shared, closing one resource should not close
all the other ones, but also not result in any leaks (this ties into the
previous point -- you can't just use zend_list_delete for that!) You may
need to implement a double resource indirection to properly handle this,
one holding the actual connection and another holding the connection
resource.

If you or someone who is familiar with interbase could fix these issues,
that would be highly appreciated.

Thanks,
Nikita
On 20/06/18 10:25, Nikita Popov wrote:
> Just to clarify which bug I was referring to in that mail, it's this one:
> https://bugs.php.net/bug.php?id=72175
>
> There are three issues that must be addressed:
> * The issue in the original bug report: Connecting to the same DB multiple
> times does not work.
> * The use of zend_list_delete() in *_close() functions, which is
> memory-unsafe.
> * Incorrect interaction of closing and multiple shared connections. While
> the underlying connection is shared, closing one resource should not close
> all the other ones, but also not result in any leaks (this ties into the
> previous point -- you can't just use zend_list_delete for that!) You may
> need to implement a double resource indirection to properly handle this,
> one holding the actual connection and another holding the connection
> resource.
>
> If you or someone who is familiar with interbase could fix these issues,
> that would be highly appreciated.

Is there anything in the changes to the code in PHP7 that are ACTUALLY
to do with changes to interbase/firebird? On website systems I only ever
have a 'singleton' database connection so don't hit this problem, but
having just spent half an hour looking through the various notes on
different lists it seems to be the way zend handles resources in PHP7
rather than anything to do with the database? THIS is where the nuances
of PHP7 need to be understood to be able to read your third point ...
where does one need to understand how the database works?

I am assuming that my next step here is to work out how
zend_list_delete() is intended to be used, perhaps compare that with
it's use in other database drivers, and work out just what was broken in
7.0.3 and why ... and "implement a double resource indirection" ...
which is much easier to implement if you understand why it is now necessary?

--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Christoph M. Becker
[PHP-DEV] Re: [RFC] [VOTE] Cleaning up unmaintained extensions
June 27, 2018 10:50PM
On 17.06.2018 at 21:43, Stanislav Malyshev wrote:

> I would like to open the vote for the RFC about cleaning up the
> unmaintained extensions:
>
> https://wiki.php.net/rfc/umaintained_extensions
>
> The vote ends 2018-06-26 23:59 PDT.

Seems the vote should have been closed already. :)

--
Christoph M. Becker

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Stanislav Malyshev
[PHP-DEV] Re: [RFC] [VOTE] Cleaning up unmaintained extensions
June 27, 2018 11:00PM
Hi!

> Seems the vote should have been closed already. :)

Indeed! Thank you for the reminder, and sorry about me not putting
reminder on my calendar to send the email about it. So here it goes:

The vote result is 19 for and 4 against, which is 82% approving. This
means this RFC has been accepted.

I have created the page https://wiki.php.net/todo/extensions to track
extensions that currently lack proper maintainership. I will update it
and anybody interested is welcome to take part. I think we'll next have
to issue some calls for maintainership. Suggestions about venues to do
it and the texts to use for it are welcome.

--
Stas Malyshev
smalyshev@gmail.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Christoph M. Becker
[PHP-DEV] Re: [RFC] [VOTE] Cleaning up unmaintained extensions
June 28, 2018 04:00PM
On 27.06.2018 at 22:50, Stanislav Malyshev wrote:

> I have created the page https://wiki.php.net/todo/extensions to track
> extensions that currently lack proper maintainership. I will update it
> and anybody interested is welcome to take part.

I've updated the list regarding the most recent bugfix[1] for
ext/enchant. (Note that there are two categories in the bugtracker
regarding Enchant: Spelling functions/Enchant related and PECL/enchant.)
Anyhow, I think that ext/enchant desperately needs a maintainer with
regard to Enchant 2[2].

[1]
http://git.php.net/?p=php-src.git;a=commit;h=5acb8381b22f4acf629d8fc89b4e0872f1a0825c
[2] https://externals.io/message/100882

--
Christoph M. Becker

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 20/06/18 05:46, Stanislav Malyshev wrote:
> Hi!
>
>> Hi!
>>
>> I would like to open the vote for the RFC about cleaning up the
>> unmaintained extensions:
>>
>> https://wiki.php.net/rfc/umaintained_extensions
>> https://wiki.php.net/rfc/umaintained_extensions
>>
>> The vote ends 2018-06-26 23:59 PDT.
>>
>>
>> Just to be sure consequence of "readline" removal.
>>
>> With CLI, "php -a" and "history" works without readline?
>> Does it work as dynamically loaded module?
>
> CLI can still use readline library. This would be about readline PHP
> extension.
>

Actually, readline support in "php -a" is part of the extension. The
extension hooks the SAPI module. See PHP_MINIT_FUNCTION(cli_readline)
in readline_cli.c.

Readline is the only extension in your list that I would be sad about
losing. I use it every day, I guess a lot of devs do.

-- Tim Starling

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 20/06/18 05:46, Stanislav Malyshev wrote:
> Hi!
>
>> Hi!
>>
>> I would like to open the vote for the RFC about cleaning up the
>> unmaintained extensions:
>>
>> https://wiki.php.net/rfc/umaintained_extensions
>> https://wiki.php.net/rfc/umaintained_extensions
>>
>> The vote ends 2018-06-26 23:59 PDT.
>>
>>
>> Just to be sure consequence of "readline" removal.
>>
>> With CLI, "php -a" and "history" works without readline?
>> Does it work as dynamically loaded module?
>
> CLI can still use readline library. This would be about readline PHP
> extension.
>

Actually, readline support in "php -a" is part of the extension. The
extension hooks the SAPI module. See PHP_MINIT_FUNCTION(cli_readline)
in readline_cli.c.

Readline is the only extension in your list that I would be sad about
losing. I use it every day, I guess a lot of devs do.

-- Tim Starling

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi!


> Readline is the only extension in your list that I would be sad about
> losing. I use it every day, I guess a lot of devs do.

It's not "losing", per se, as the code doesn't get erased, it just moved
to PECL. All distros can build it from there just as they do now. Then
again, if it's super-important and doesn't have any major issues, we
could keep it (or any other extension) around in "community maintained"
status for a while.

--
Stas Malyshev
smalyshev@gmail.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi,

On Fri, Jun 29, 2018 at 9:39 AM, Stanislav Malyshev <[email protected]> wrote:
> Hi!
>
>
>> Readline is the only extension in your list that I would be sad about
>> losing. I use it every day, I guess a lot of devs do.
>
> It's not "losing", per se, as the code doesn't get erased, it just moved
> to PECL. All distros can build it from there just as they do now. Then
> again, if it's super-important and doesn't have any major issues, we
> could keep it (or any other extension) around in "community maintained"
> status for a while.
>

If "php -a" doesn't work without ext/readline (and I know it never
works for me if I don't install the distro-provided php-readline
package), then it is super-important.

Cheers,
Andrey.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 29.06.2018 at 16:54, Andrey Andreev wrote:

> On Fri, Jun 29, 2018 at 9:39 AM, Stanislav Malyshev <[email protected]> wrote:
>>
>>> Readline is the only extension in your list that I would be sad about
>>> losing. I use it every day, I guess a lot of devs do.
>>
>> It's not "losing", per se, as the code doesn't get erased, it just moved
>> to PECL. All distros can build it from there just as they do now. Then
>> again, if it's super-important and doesn't have any major issues, we
>> could keep it (or any other extension) around in "community maintained"
>> status for a while.
>
> If "php -a" doesn't work without ext/readline (and I know it never
> works for me if I don't install the distro-provided php-readline
> package), then it is super-important.

It's not about removing readline support for the interactive PHP shell,
see <https://externals.io/message/102282#102307>;.

--
Christoph M. Becker

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi again,

On Fri, Jun 29, 2018 at 6:07 PM, Christoph M. Becker <[email protected]> wrote:
> On 29.06.2018 at 16:54, Andrey Andreev wrote:
>
>> On Fri, Jun 29, 2018 at 9:39 AM, Stanislav Malyshev <[email protected]> wrote:
>>>
>>>> Readline is the only extension in your list that I would be sad about
>>>> losing. I use it every day, I guess a lot of devs do.
>>>
>>> It's not "losing", per se, as the code doesn't get erased, it just moved
>>> to PECL. All distros can build it from there just as they do now. Then
>>> again, if it's super-important and doesn't have any major issues, we
>>> could keep it (or any other extension) around in "community maintained"
>>> status for a while.
>>
>> If "php -a" doesn't work without ext/readline (and I know it never
>> works for me if I don't install the distro-provided php-readline
>> package), then it is super-important.
>
> It's not about removing readline support for the interactive PHP shell,
> see <https://externals.io/message/102282#102307>;.
>

I know it's not about that, but the problem is that currently (or on
7.0.x at least) the interactive shell doesn't work without the
extension.

Cheers,
Andrey.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Fri, Jun 29, 2018 at 2:16 PM, Tim Starling <[email protected]>
wrote:

> On 20/06/18 05:46, Stanislav Malyshev wrote:
> > Hi!
> >
> >> Hi!
> >>
> >> I would like to open the vote for the RFC about cleaning up the
> >> unmaintained extensions:
> >>
> >> https://wiki.php.net/rfc/umaintained_extensions
> >> https://wiki.php.net/rfc/umaintained_extensions
> >>
> >> The vote ends 2018-06-26 23:59 PDT.
> >>
> >>
> >> Just to be sure consequence of "readline" removal.
> >>
> >> With CLI, "php -a" and "history" works without readline?
> >> Does it work as dynamically loaded module?
> >
> > CLI can still use readline library. This would be about readline PHP
> > extension.
> >
>
> Actually, readline support in "php -a" is part of the extension. The
> extension hooks the SAPI module. See PHP_MINIT_FUNCTION(cli_readline)
> in readline_cli.c.
>
> Readline is the only extension in your list that I would be sad about
> losing. I use it every day, I guess a lot of devs do.
>

readline has license issue. I miss it but I wouldn't object for removing it.
Let's use libedit for CLI by default and always.
Issue may be who is going to do this. If nobody volunteers, I may do this.

--
Yasuo Ohgaki
On 30/06/18 11:44, Yasuo Ohgaki wrote:
> readline has license issue. I miss it but I wouldn't object for removing it.
> Let's use libedit for CLI by default and always.
> Issue may be who is going to do this. If nobody volunteers, I may do this.

The discussion is about the readline extension, which includes support
for both libedit and the GNU Readline library. You can't use libedit
without the readline extension.

-- Tim Starling

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Sat, Jun 30, 2018 at 11:42 AM, Tim Starling <[email protected]>
wrote:

> On 30/06/18 11:44, Yasuo Ohgaki wrote:
> > readline has license issue. I miss it but I wouldn't object for removing
> it.
> > Let's use libedit for CLI by default and always.
> > Issue may be who is going to do this. If nobody volunteers, I may do
> this.
>
> The discussion is about the readline extension, which includes support
> for both libedit and the GNU Readline library. You can't use libedit
> without the readline extension.
>

../configure --without-readline
makes CLI binary with broken "-a" support as you know.

I'm suggesting libedit capability for CLI binary "without" readline module.
i.e. Statically compiled libedit support in CLI binary.

--
Yasuo Ohgaki
Sorry, only registered users may post in this forum.

Click here to login