Everything

php

pending CVS massaging

php.internals

Wez Furlong

22 years ago

Following up from Jani's mail regarding pecl picking,
I will be tweaking CVSROOT/modules later tonight so that
our "golden" pecl packages get checked out along with the
php sources.

This includes removing the symlink that links pecl/sqlite
into ext (as it would be redundant).

Once the change is made, you will need to check out the source
again to pick up the extensions; you can check out over the top
of your existing working directory and CVS will be smart
enough to only fetch the things you need, so this shouldn't
pose a problem.

This is just an advance warning; nothing has changed yet.

--Wez.

Sascha Schumann

22 years ago

We agreed *not* to rely on modules for this kind of
procedure, because it effectively disables "cvs upd -d".

Please explain what problem you are trying to solve and we
will find an alternative.

- Sascha

On Thu, 4 Dec 2003, Wez Furlong wrote:

Jani Taskinen

22 years ago

The adding of modules happens VERY rarely.
So your "disables cvs upd -d" is not very good argument
against this. And there is no alternative way anyway..
If you know such, PLEASE do tell us. :)

--Jani

On Thu, 4 Dec 2003, Sascha Schumann wrote:

Sascha Schumann

22 years ago

On Thu, 4 Dec 2003, Jani Taskinen wrote:

>
>     The adding of modules happens VERY rarely.
>     So your "disables cvs upd -d" is not very good argument
>     against this. And there is no alternative way anyway..
>     If you know such, PLEASE do tell us. :)

The symlinks are the only transparent way.

Remember the big fight with James about this issue?  He
wanted to do the same thing as Wez is proposing.

- Sascha

Edin Kadribasic

22 years ago

On Thursday, Dec 4, 2003, at 15:05 Europe/Copenhagen, Sascha Schumann
wrote:

> On Thu, 4 Dec 2003, Jani Taskinen wrote:
>
>>
>>     The adding of modules happens VERY rarely.
>>     So your "disables cvs upd -d" is not very good argument
>>     against this. And there is no alternative way anyway..
>>     If you know such, PLEASE do tell us. :)
>
>     The symlinks are the only transparent way.
>
>     Remember the big fight with James about this issue?  He
>     wanted to do the same thing as Wez is proposing.

Well, symlinks turned out to be even bigger headache. It makes having
different versions of extensions in PECL nearly impossible.

The most obvious example is sqlite which supports php4 but is not part
of it, while its bundled and enabled by default in php5.

Now with php5-bundle cvs module that specifies all the pecl modules
included in the distribution this is easy to solve.

Edin

Sascha Schumann

22 years ago

Let me try to understand what the problem might be.

- php 5 version of sqlite should check out with php-src, branch head
- php 4 version of sqlite should not check out with php-src, branch PHP_4_3
- php 4 version of sqlite should be checkoutable separately

Right?

So:

- develop php 5 version of sqlite on the head branch
- empty the PHP_4_3 branch
- develop php 4 version of sqlite on a custom branch
(e.g. SQLITE_PHP_4)

I don't see a problem.  Do you?

- Sascha

> Well, symlinks turned out to be even bigger headache. It makes having
> different versions of extensions in PECL nearly impossible.
>
> The most obvious example is sqlite which supports php4 but is not part
> of it, while its bundled and enabled by default in php5.
>
> Now with php5-bundle cvs module that specifies all the pecl modules
> included in the distribution this is easy to solve.

- Sascha

Edin Kadribasic

22 years ago

On Thursday, Dec 4, 2003, at 15:25 Europe/Copenhagen, Sascha Schumann
wrote:

>     Let me try to understand what the problem might be.
>
>     - php 5 version of sqlite should check out with php-src, branch
> head
>     - php 4 version of sqlite should not check out with php-src,
> branch PHP_4_3
>     - php 4 version of sqlite should be checkoutable separately
>
>     Right?
>
>     So:
>
>     - develop php 5 version of sqlite on the head branch
>     - empty the PHP_4_3 branch
>     - develop php 4 version of sqlite on a custom branch
>       (e.g. SQLITE_PHP_4)

- insert a symlink on the cvs server direcly

Yeah we came up with that solution at the end. Except sqlite module
already used PHP_4_3 branch so when Jani deleted it it went missing.
Eventually we had to come up with PECL_4_3 branch so that php4 users
could use sqlite.

I see this as one big mess. Don't you?

Edin

Sascha Schumann

22 years ago

> - insert a symlink on the cvs server direcly
>
> Yeah we came up with that solution at the end.

That must have been difficult, considering its extensive
discussion on this list in the past. :-)

> Except sqlite module
> already used PHP_4_3 branch so when Jani deleted it it went missing.

I did not see a post on internals or even systems regarding
this matter.  Did you 'decide' this on IRC?

> Eventually we had to come up with PECL_4_3 branch so that php4 users
> could use sqlite.
>
> I see this as one big mess. Don't you?

Nope.  It is very strict, it is the same procedure for every
module, it is clearly defined.  No mess at all.

- Sascha

Pierre-Alain Joye

22 years ago

On Thu, 4 Dec 2003 16:00:47 +0200 (EET)
Jani Taskinen <sniper@iki.fi> wrote:

>
>     The adding of modules happens VERY rarely.
>     So your "disables cvs upd -d" is not very good argument
>     against this. And there is no alternative way anyway..
>     If you know such, PLEASE do tell us. :)

Keep them in PECL and work on a per release basis (and avoid these
annoyed MFH and related things :D )? or aka php5-bundle definitions
described by Edin.

Then it should be easy to call 'pear bundle' (or alter this command
to fit our needs) to generate the release files for sources distros or
snaps. CVS users can add manually the required symlinks if they like to
use the respective head of each extension branches.

OK I'm off ;-)

pierre