Everything

php

phpenmod/phpdismod

php.internals

Legale Legage

7 years ago

Hello, internal.

I want to propose including to the bundle phpenmod/phpdismod scripts. These
scripts are included to the standard deb/rpm packages. What do you think
about including them to the bundle?

If the idea is worthwhile, I will make the RFC.

Saluti, Ruslan

Joe Watkins

7 years ago

Hi Legale,

In general we leave the packaging of PHP to the packaging experts. So I
doubt if there's much need to include these in php-src, but let's see what
others have to say ?

Cheers
Joe

On Sat, 2 Feb 2019 at 20:24, Legale Legage <legale.legale@gmail.com> wrote:

Stas Malyshev

7 years ago

Hi!

>> I want to propose including to the bundle phpenmod/phpdismod scripts. These

I'm sorry but what these scripts are? What do they do?

--
Stas Malyshev
smalyshev@gmail.com

Legale Legage

7 years ago

These scripts allow you to enable/disable php shared extensions.

On Sat, 2 Feb 2019 at 21:00, Stanislav Malyshev <smalyshev@gmail.com> wrote:

Stas Malyshev

7 years ago

Hi!

On 2/2/19 12:34 PM, Legale Legage wrote:

> These scripts allow you to enable/disable php shared extensions.

What you mean by enable/disable? Could you describe a use case for why
this script would be used by a developer? Or is this meant for the user
- then why the script would be used by the user?

--
Stas Malyshev
smalyshev@gmail.com

Legale Legage

7 years ago

As a man, being a user at 99%. it has always been very important to have
such useful things.
At the moment bundle is already generating  init.d and systemd scripts. So
why not phpenmod / phpdismod?
I think usability can not be too much.

Sincerely,
Ruslan


On Sat, 2 Feb 2019 at 20:37, Joe Watkins <krakjoe@gmail.com> wrote:

Peter Kokot

7 years ago

On Sat, 2 Feb 2019 at 20:24, Legale Legage <legale.legale@gmail.com> wrote:

>
> Hello, internal.
>
> I want to propose including to the bundle phpenmod/phpdismod scripts. These
> scripts are included to the standard deb/rpm packages. What do you think
> about including them to the bundle?
>
> If the idea is worthwhile, I will make the RFC.
>
> Saluti, Ruslan

1. Will it work also on Alpine Linux and MacOS? From what I see, the
title of these two POSIX shell scripts is "phpenmod - a PHP module
manager for Debian"
2. License MIT will cause any issues with bundling them in php-src?
3. Do you know where is the source code of these two scripts? When the
upstream script gets updated it would be then useful to copy/paste
changes into php-src. So the main development should be happening
upstream anyway. Meaning away from the PHP.

What these two scripts do is they enable "extensions" on Debian
installation. For example, phpenmod ftp
Some naming conventions name the PHP extensions (bcmath, openssl,
sodium...) also "modules". So, overall, nothing very simple to create
for all operating systems. Each Linux distribution has different
package repositories, locations to shared extension ini files, so that
is in this situation probably good to be left to 3rd party repository
maintainers or the Linux distro packages maintainers themselves.

Yes CLI tooling arsenal for more systems/devops oriented PHP world are
in need of improvements. There are many that lack handling extensions
(we were just discussing PECL for example in some other thread)...

--
Peter Kokot

Legale Legage

7 years ago

On Sat, 2 Feb 2019 at 20:57, Peter Kokot <peterkokot@gmail.com> wrote:

> On Sat, 2 Feb 2019 at 20:24, Legale Legage <legale.legale@gmail.com>
> wrote:
> >
> > Hello, internal.
> >
> > I want to propose including to the bundle phpenmod/phpdismod scripts.
> These
> > scripts are included to the standard deb/rpm packages. What do you think
> > about including them to the bundle?
> >
> > If the idea is worthwhile, I will make the RFC.
> >
> > Saluti, Ruslan
>
> 1. Will it work also on Alpine Linux and MacOS? From what I see, the
> title of these two POSIX shell scripts is "phpenmod - a PHP module
> manager for Debian"

It depends on us. We can make special scripts for MacOS and even Windows
:-).

> 2. License MIT will cause any issues with bundling them in php-src?
>

License allows it. Moreover, i think the author (Ondrej Sury) will be
pleased
if his creation will be included in the bundle.

> 3. Do you know where is the source code of these two scripts? When the
> upstream script gets updated it would be then useful to copy/paste
> changes into php-src. So the main development should be happening
> upstream anyway. Meaning away from the PHP.
>

I don't know what to say on that.

>
> What these two scripts do is they enable "extensions" on Debian
> installation. For example, phpenmod ftp
> Some naming conventions name the PHP extensions (bcmath, openssl,
> sodium...) also "modules". So, overall, nothing very simple to create
> for all operating systems. Each Linux distribution has different
> package repositories, locations to shared extension ini files, so that
> is in this situation probably good to be left to 3rd party repository
> maintainers or the Linux distro packages maintainers themselves.
>
> Most likely it will not be easy.

> Yes CLI tooling arsenal for more systems/devops oriented PHP world are
> in need of improvements. There are many that lack handling extensions
> (we were just discussing PECL for example in some other thread)...
>
> Perhaps the presence of such scripts in the bundle will push the

unification
process on different systems. In any case, you can always make your own
way and not use these scripts.

> --
> Peter Kokot

On Sat, 2 Feb 2019 at 20:57, Peter Kokot <peterkokot@gmail.com> wrote:

Peter Kokot

7 years ago

>> 3. Do you know where is the source code of these two scripts? When the
>> upstream script gets updated it would be then useful to copy/paste
>> changes into php-src. So the main development should be happening
>> upstream anyway. Meaning away from the PHP.
>
>
> I don't know what to say on that.

P.S. I've found sources at Debian mainstream:
https://sources.debian.org/src/php-defaults/69/php-helper/

Overall, I think this might be too Debian specific tool. PECL is
something that works in similar way. And it installs entire extension
from scratch together with compiling... PECL approach is something
that PHP should go into. Or, the more taboo way - Composer installable
extensions. There was some work done on that but it got stuck because
it is very large change and now nobody knows how to do that from that
step. Basically, a Composer plugin might be a better start with this.
Except that here we need to understand that PHP packages on Linux
distributions are already compiled and prepared for faster
installation, so installing extensions with PECL is a way different
approach compared to a more comfortable ways using
apt/yum/dnf/pacman/brew...

--
Peter Kokot

Walter Parker

7 years ago

On Sat, Feb 2, 2019 at 1:06 PM Peter Kokot <peterkokot@gmail.com> wrote:

> >> 3. Do you know where is the source code of these two scripts? When the
> >> upstream script gets updated it would be then useful to copy/paste
> >> changes into php-src. So the main development should be happening
> >> upstream anyway. Meaning away from the PHP.
> >
> >
> > I don't know what to say on that.
>
> P.S. I've found sources at Debian mainstream:
> https://sources.debian.org/src/php-defaults/69/php-helper/
>
> Overall, I think this might be too Debian specific tool. PECL is
> something that works in similar way. And it installs entire extension
> from scratch together with compiling... PECL approach is something
> that PHP should go into. Or, the more taboo way - Composer installable
> extensions. There was some work done on that but it got stuck because
> it is very large change and now nobody knows how to do that from that
> step. Basically, a Composer plugin might be a better start with this.
> Except that here we need to understand that PHP packages on Linux
> distributions are already compiled and prepared for faster
> installation, so installing extensions with PECL is a way different
> approach compared to a more comfortable ways using
> apt/yum/dnf/pacman/brew...
>
> --
> Peter Kokot
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

If you can make it work on MacOS, Windows, and the BSDs, then great.
Otherwise, it should be left to the Linux distributions.


Walter

--
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding.   -- Justice Louis D. Brandeis

Lester Caine

7 years ago

On 03/02/2019 02:44, Walter Parker wrote:

> If you can make it work on MacOS, Windows, and the BSDs, then great.
> Otherwise, it should be left to the Linux distributions.

And bare in mind that there are a number of different standards
CURRENTLY used across the different LINUX distributions! The question of
managing selection of what extensions ARE loaded is a minefield in it's
own right ... and just where they are loaded by default.

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

Remi Collet

7 years ago

Hi,

Le 02/02/2019 à 20:24, Legale Legage a écrit :

> These scripts are included to the standard deb/rpm packages

No, this is a deb only stuff

RPM installed = extension enabled.

Remi

P.S. I have never understand the need of such tools...
did it made sense in previous century, where download have a cost ?

BTW, on package linux distro, when I install a webapp which depends on
some extensions, I obviously expect than everything needed is enabled...

Markus Fischer

7 years ago

Hi,

On 04.02.19 07:24, Remi Collet wrote:

> Le 02/02/2019 à 20:24, Legale Legage a écrit :
>> These scripts are included to the standard deb/rpm packages
>
> No, this is a deb only stuff
>
> RPM installed = extension enabled.
>
>
> Remi
>
>
> P.S. I have never understand the need of such tools...
> did it made sense in previous century, where download have a cost ?

I find them mostly useful when developing and sometimes useful when in
production to not have to navigate around the filesystem how to
enable/disable.

Need ensure my unit tests don't accidentally use redis? `phpdismod
redis` and done. For all installed PHP versions (maybe due to using the
popule Ondrey packages though).

Temporarily disble opcache in production because I suspect an issue with
it? `phpdismod opcache`, reload FPM and done. Don't have to remember
which exact directory/file which is like
`/etc/php/<major>.<minor>/mods-available/ .

That said, it seems really distribution specific to me too.

- Markus

Stas Malyshev

7 years ago

Hi!

>> P.S. I have never understand the need of such tools...
>> did it made sense in previous century, where download have a cost ?

Enabling/disabling extensions can be useful for many scenario, both in
testing and development - such as testing various branches of code, see
proper error handling, etc. However, in my opinion, such scripts can be
in core only if they can be made to work in all or overwhelming majority
of deployments, which doesn't seem to be the case here.

--
Stas Malyshev
smalyshev@gmail.com

Johannes Schlueter

7 years ago

On Mo, 2019-02-04 at 07:24 +0100, Remi Collet wrote:

> 
> P.S. I have never understand the need of such tools...
> did it made sense in previous century, where download have a cost ?
>
> BTW, on package linux distro, when I install a webapp which depends
> on
> some extensions, I obviously expect than everything needed is
> enabled...

I have no insight into Debian/Ubuntu's reasoning, but I think a factor
is that sometimes you want stuff only in some SAPI. Obviously readline
and pcntl are not good in apache sapis. (well and after those my
examples end and those could also be handled by the packaging system
...) and I thnk the logic follows their way of handling i.e. apache
modules which have to be enabled a2enmod/a2dismod.

Anyways, the feature in this way has little use in current vanilla PHP
and is more a topic for when we revamp the pecl/extension handling.

johannes

Lester Caine

7 years ago

On 04/02/2019 06:24, Remi Collet wrote:

> P.S. I have never understand the need of such tools...
> did it made sense in previous century, where download have a cost ?
>
> BTW, on package linux distro, when I install a webapp which depends on
> some extensions, I obviously expect than everything needed is enabled...

It's nice to be able to ignore MySQL and Postgres when one is not using
them in production, so the ability simply to load those extensions one
actually uses is a nice to have ...

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