# Move old (or non-mainstream) extensions to PECL before beta 3 - Thread: https://externals.io/message/5808 - Original archive: https://news-web.php.net/php.internals/5808 - Started by magnus@php.net on 2003-11-30T08:18:13+00:00 - Messages: 18 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #5808 — magnus@php.net — 2003-11-30T08:18:13+00:00 URL: https://externals.io/message/5808#5808 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. --- ## #5811 — Wez Furlong — 2003-11-30T09:40:56+00:00 URL: https://externals.io/message/5808#5811 · In reply to: #5808 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 ;-) --- ## #5813 — Jani Taskinen — 2003-11-30T09:44:56+00:00 URL: https://externals.io/message/5808#5813 · In reply to: #5811 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. > > > […] >extensions > > […] >of > > […] > >Especially at PHP conferences in germany ;-) --- ## #5815 — Wez Furlong — 2003-11-30T09:47:31+00:00 URL: https://externals.io/message/5808#5815 · In reply to: #5813 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 --- ## #5817 — Jani Taskinen — 2003-11-30T09:52:07+00:00 URL: https://externals.io/message/5808#5817 · In reply to: #5815 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. > > > […] --- ## #5820 — Wez Furlong — 2003-11-30T10:01:51+00:00 URL: https://externals.io/message/5808#5820 · In reply to: #5817 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 --- ## #5824 — Marcus Boerger — 2003-11-30T12:35:23+00:00 URL: https://externals.io/message/5808#5824 · In reply to: #5820 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 --- ## #5826 — Derick Rethans — 2003-11-30T12:39:36+00:00 URL: https://externals.io/message/5808#5826 · In reply to: #5824 > Hello Wez, > > Sunday, November 30, 2003, 11:01:51 AM, you wrote: > > > […] > > 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 --- ## #5827 — Marcus Boerger — 2003-11-30T12:46:53+00:00 URL: https://externals.io/message/5808#5827 · In reply to: #5826 Hello Derick, Sunday, November 30, 2003, 1:39:36 PM, you wrote: > > > […] > 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 --- ## #5828 — Wez Furlong — 2003-11-30T12:52:41+00:00 URL: https://externals.io/message/5808#5828 · In reply to: #5827 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. > > […] that we > > […] for > > […] > > > […] > > 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. --- ## #5830 — Sara Golemon — 2003-11-30T17:35:31+00:00 URL: https://externals.io/message/5808#5830 · In reply to: #5828 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" Newsgroups: php.internals To: 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. > > > […] > that we > > […] the > > […] > for > > […] --- ## #5831 — Jani Taskinen — 2003-11-30T17:59:02+00:00 URL: https://externals.io/message/5808#5831 · In reply to: #5828 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. > > > […] >that we > > […] >for > > […] --- ## #5832 — Derick Rethans — 2003-11-30T18:03:15+00:00 URL: https://externals.io/message/5808#5832 · In reply to: #5831 > > 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 --- ## #5833 — Jani Taskinen — 2003-11-30T18:06:49+00:00 URL: https://externals.io/message/5808#5833 · In reply to: #5832 > > > > […] > >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 --- ## #5834 — Derick Rethans — 2003-11-30T18:09:48+00:00 URL: https://externals.io/message/5808#5834 · In reply to: #5833 > > > > […] > > 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 --- ## #5835 — Ilia Alshanetsky — 2003-11-30T19:05:18+00:00 URL: https://externals.io/message/5808#5835 · In reply to: #5830 > 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 --- ## #5850 — Marcus Boerger — 2003-12-01T07:01:00+00:00 URL: https://externals.io/message/5808#5850 · In reply to: #5824 Hello Marcus, Sunday, November 30, 2003, 1:35:23 PM, you wrote: > Hello Wez, > Sunday, November 30, 2003, 11:01:51 AM, you wrote: > > […] > 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 --- ## #5966 — Stig S. Bakken — 2003-12-01T23:15:05+00:00 URL: https://externals.io/message/5808#5966 · In reply to: #5831 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 > > > > > […]