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.
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 ;-)
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 ;-)
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
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
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
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
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
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
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.
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.
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
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.
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
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
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
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?) --JaniHey, 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.
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