Move old (or non-mainstream) extensions to PECL before beta 3

21 years ago by magnus@php.net — view source

unread

Hello!

Maybe we should move extensions like dbase, ovrimos, ingress_ii, qtdom &
pfpro to PECL before releasing beta 3 ?

Wez said, on IRC, that we need a script to pick out the "golden" extensions
for bundling, but Ilia pointed out that there's nothing golden about a few of
these.

/Magnus

--
Caution: breathing may be hazardous to your health.

21 years ago by Wez Furlong — view source

unread

The point is that there is no need to waste time moving
things around if there is no build infrastructure in place.
Having these extensions in php-src/ext is no different to
having them in pecl/ except that they currently build under
ext, but would require work to make them build under pecl.

They are not hurting anyone where they are, so I suggest
that it would be better to put the effort into the distro
building script first, and then (if you're bored ;-) move
these not-so-golden extensions into pecl.

--Wez.

Maybe we should move extensions like dbase, ovrimos, ingress_ii, qtdom &
pfpro to PECL before releasing beta 3 ?

Wez said, on IRC, that we need a script to pick out the "golden"
extensions
for bundling, but Ilia pointed out that there's nothing golden about a few
of
these.

Caution: breathing may be hazardous to your health.

Especially at PHP conferences in germany ;-)

21 years ago by Jani Taskinen — view source

unread

I think the point in moving them to PECL is to make
people realize that they are not supported. :)

--Jani

p.s. Can someone PLEASE nuke ext/db finally?!

The point is that there is no need to waste time moving
things around if there is no build infrastructure in place.
Having these extensions in php-src/ext is no different to
having them in pecl/ except that they currently build under
ext, but would require work to make them build under pecl.

They are not hurting anyone where they are, so I suggest
that it would be better to put the effort into the distro
building script first, and then (if you're bored ;-) move
these not-so-golden extensions into pecl.

--Wez.

Maybe we should move extensions like dbase, ovrimos, ingress_ii, qtdom &
pfpro to PECL before releasing beta 3 ?

Wez said, on IRC, that we need a script to pick out the "golden"
extensions
for bundling, but Ilia pointed out that there's nothing golden about a few
of
these.

Caution: breathing may be hazardous to your health.

Especially at PHP conferences in germany ;-)

21 years ago by Wez Furlong — view source

unread

Then why not make a new module called "unsupported" and put them
in there? PECL is not siberia.

--Wez.

I think the point in moving them to PECL is to make
people realize that they are not supported. :)

--Jani

21 years ago by Jani Taskinen — view source

unread

I didn't mean they would be totally unaccesible.
Just not supported in the main distribution..
    
--Jani

Then why not make a new module called "unsupported" and put them
in there? PECL is not siberia.

--Wez.
I think the point in moving them to PECL is to make
people realize that they are not supported. :)

--Jani

21 years ago by Wez Furlong — view source

unread

There is no point moving unmaintained code from ext to pecl;
its just a waste of time until we can solve the problem at
packaging time, which is why I'm suggesting that one of the build
guru's that hates these unmaintained extensions cough Jani
cough should work on the distro building tool which we
will need real soon now anyway. ;-)

--Wez.

I didn't mean they would be totally unaccesible.
Just not supported in the main distribution..
    
--Jani

21 years ago by Marcus Boerger — view source

unread

Hello Wez,

Sunday, November 30, 2003, 11:01:51 AM, you wrote:

There is no point moving unmaintained code from ext to pecl;
its just a waste of time until we can solve the problem at
packaging time, which is why I'm suggesting that one of the build
guru's that hates these unmaintained extensions cough Jani
cough should work on the distro building tool which we
will need real soon now anyway. ;-)

Why not go with RPM's then? The eays way is to split up the RPM's so that we
can have RPMs for the basic stuff like INI, Docs and all, then for the
different sapis and then for all the extensions. See attached makerpm for
current state of work.

Best regards,
Marcus mailto:helly@php.net

21 years ago by Derick Rethans — view source

unread

Hello Wez,

Sunday, November 30, 2003, 11:01:51 AM, you wrote:

There is no point moving unmaintained code from ext to pecl;
its just a waste of time until we can solve the problem at
packaging time, which is why I'm suggesting that one of the build
guru's that hates these unmaintained extensions cough Jani
cough should work on the distro building tool which we
will need real soon now anyway. ;-)

Why not go with RPM's then? The eays way is to split up the RPM's so that we
can have RPMs for the basic stuff like INI, Docs and all, then for the
different sapis and then for all the extensions. See attached makerpm for
current state of work.

How do RPMs work on Gentoo, Debian, Windows, MacOSX...?

Derick

21 years ago by Marcus Boerger — view source

unread

Hello Derick,

Sunday, November 30, 2003, 1:39:36 PM, you wrote:

Hello Wez,

Sunday, November 30, 2003, 11:01:51 AM, you wrote:

There is no point moving unmaintained code from ext to pecl;
its just a waste of time until we can solve the problem at
packaging time, which is why I'm suggesting that one of the build
guru's that hates these unmaintained extensions cough Jani
cough should work on the distro building tool which we
will need real soon now anyway. ;-)

Why not go with RPM's then? The eays way is to split up the RPM's so that we
can have RPMs for the basic stuff like INI, Docs and all, then for the
different sapis and then for all the extensions. See attached makerpm for
current state of work.

How do RPMs work on Gentoo, Debian, Windows, MacOSX...?

It is impossible to find a solution that works for all systems. This RPM
stuff at least is a way for all *nix systems. So the main problem is
Windows again.

--
Best regards,
Marcus mailto:helly@php.net

21 years ago by Wez Furlong — view source

unread

Hey, all I'm talking about is a script to put the golden extensions
into ext (and exclude the cruft) when we build our tarball distro.

--Wez.

Why not go with RPM's then? The eays way is to split up the RPM's so
that we
can have RPMs for the basic stuff like INI, Docs and all, then for the
different sapis and then for all the extensions. See attached makerpm
for
current state of work.

How do RPMs work on Gentoo, Debian, Windows, MacOSX...?

It is impossible to find a solution that works for all systems. This RPM
stuff at least is a way for all *nix systems. So the main problem is
Windows again.

21 years ago by Sara Golemon — view source

unread

Perhaps I'm confused.....

I had the impression that the point of moving obsolesced extensions to PECL
was so that they WOULDN'T be included in the main source tarball. Then,
should user X out there need ext/foo they can do a: pear install foo.

If >that's< the case, then there need be no "pic up golden extensions at
bundle time" script. The creation of a tarball is just what it already is.

Are there any PECL extensions other than SQLite which are bundled at package
time?

What am I missing?

-Sara

----- Original Message -----
From: "Wez Furlong" wez@thebrainroom.com
Newsgroups: php.internals
To: internals@lists.php.net
Sent: Sunday, November 30, 2003 4:52 AM
Subject: Re: [PHP-DEV] Move old (or non-mainstream) extensions to PECL
before beta 3

Hey, all I'm talking about is a script to put the golden extensions
into ext (and exclude the cruft) when we build our tarball distro.

--Wez.

Why not go with RPM's then? The eays way is to split up the RPM's so
that we
can have RPMs for the basic stuff like INI, Docs and all, then for
the
different sapis and then for all the extensions. See attached makerpm
for
current state of work.

How do RPMs work on Gentoo, Debian, Windows, MacOSX...?

It is impossible to find a solution that works for all systems. This RPM
stuff at least is a way for all *nix systems. So the main problem is
Windows again.

21 years ago by Ilia Alshanetsky — view source

unread

Perhaps I'm confused.....

I had the impression that the point of moving obsolesced extensions to PECL
was so that they WOULDN'T be included in the main source tarball. Then,
should user X out there need ext/foo they can do a: pear install foo.

If >that's< the case, then there need be no "pic up golden extensions at
bundle time" script. The creation of a tarball is just what it already is.

I guess I am confused as well, because I was under the same impression.
My reasoning for removing obsolete extensions was to prevent dead (often
poorly working code) from making it to the default distribution, which result
in all kinds of problems.

Are there any PECL extensions other than SQLite which are bundled at
package time?

bz2 (in php5).

Ilia

21 years ago by Jani Taskinen — view source

unread

I kinda have thought all the time that those extensions
that will be in a release stay in the php-src CVS module.
And the rest is put into PECL, where people can find them
and use phpize or whatever to build them.

Doesn't that 'pear install' thing work already? (sqlite, anyone?)

--Jani

Hey, all I'm talking about is a script to put the golden extensions
into ext (and exclude the cruft) when we build our tarball distro.

--Wez.

Why not go with RPM's then? The eays way is to split up the RPM's so
that we
can have RPMs for the basic stuff like INI, Docs and all, then for the
different sapis and then for all the extensions. See attached makerpm
for
current state of work.

How do RPMs work on Gentoo, Debian, Windows, MacOSX...?

It is impossible to find a solution that works for all systems. This RPM
stuff at least is a way for all *nix systems. So the main problem is
Windows again.

21 years ago by Derick Rethans — view source

unread

I kinda have thought all the time that those extensions
that will be in a release stay in the php-src CVS module.
And the rest is put into PECL, where people can find them
and use phpize or whatever to build them.

Doesn't that 'pear install' thing work already? (sqlite, anyone?)

SQlite is already in the normal tree, and pear install worked for PECL
extensions, but recently somebody broke that.

Derick

21 years ago by Jani Taskinen — view source

unread

I kinda have thought all the time that those extensions
that will be in a release stay in the php-src CVS module.
And the rest is put into PECL, where people can find them
and use phpize or whatever to build them.

Doesn't that 'pear install' thing work already? (sqlite, anyone?)

SQlite is already in the normal tree, and pear install worked for PECL
extensions, but recently somebody broke that.

I meant that it has worked fine for sqlite for long time.
If someone broke the thing, that someone should fix it too.
    
--Jani

21 years ago by Derick Rethans — view source

unread

SQlite is already in the normal tree, and pear install worked for PECL
extensions, but recently somebody broke that.
I meant that it has worked fine for sqlite for long time.
If someone broke the thing, that someone should fix it too.

No disagreement there :)

Derick

21 years ago by Stig S. Bakken — view source

unread

There's also "pear bundle" now:

ssb@kirin(~/cvs/php/php5)$ pear bundle -d ext apd
downloading apd-0.4p2.tar ...
Starting to download apd-0.4p2.tar (-1 bytes)
.........................................done: 189,440 bytes
Package ready at '/home/ssb/cvs/php/php5/ext/apd'

You can do this with any PECL release or tarball. All that would be
needed is to run this command a couple of times from makedist.

Stig

I kinda have thought all the time that those extensions
that will be in a release stay in the php-src CVS module.
And the rest is put into PECL, where people can find them
and use phpize or whatever to build them.

Doesn't that 'pear install' thing work already? (sqlite, anyone?)

--Jani
Hey, all I'm talking about is a script to put the golden extensions
into ext (and exclude the cruft) when we build our tarball distro.

--Wez.

Why not go with RPM's then? The eays way is to split up the RPM's so
that we
can have RPMs for the basic stuff like INI, Docs and all, then for the
different sapis and then for all the extensions. See attached makerpm
for
current state of work.

How do RPMs work on Gentoo, Debian, Windows, MacOSX...?

It is impossible to find a solution that works for all systems. This RPM
stuff at least is a way for all *nix systems. So the main problem is
Windows again.

21 years ago by Marcus Boerger — view source

unread

Hello Marcus,

Sunday, November 30, 2003, 1:35:23 PM, you wrote:

Hello Wez,

Sunday, November 30, 2003, 11:01:51 AM, you wrote:

There is no point moving unmaintained code from ext to pecl;
its just a waste of time until we can solve the problem at
packaging time, which is why I'm suggesting that one of the build
guru's that hates these unmaintained extensions cough Jani
cough should work on the distro building tool which we
will need real soon now anyway. ;-)

Why not go with RPM's then? The eays way is to split up the RPM's so that we
can have RPMs for the basic stuff like INI, Docs and all, then for the
different sapis and then for all the extensions. See attached makerpm for
current state of work.

Hmmm, no attachement. Then here is the url:
http://marcus-boerger.de/?php/ext/makerpm

--
Best regards,
Marcus mailto:helly@php.net

Move old (or non-mainstream) extensions to PECL before beta 3

Wez said, on IRC, that we need a script to pick out the "golden" extensions for bundling, but Ilia pointed out that there's nothing golden about a few of these.

Wez said, on IRC, that we need a script to pick out the "golden" extensions for bundling, but Ilia pointed out that there's nothing golden about a few of these.

Wez said, on IRC, that we need a script to pick out the "golden"
extensions
for bundling, but Ilia pointed out that there's nothing golden about a few
of
these.

Wez said, on IRC, that we need a script to pick out the "golden"
extensions
for bundling, but Ilia pointed out that there's nothing golden about a few
of
these.