# oci in pecl...

- Thread: https://externals.io/message/6306
- Original archive: https://news-web.php.net/php.internals/6306
- Started by Thies C.Arntzen on 2003-12-09T19:12:50+00:00
- Messages: 15
- 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

---

## #6306 — Thies C.Arntzen — 2003-12-09T19:12:50+00:00

URL: https://externals.io/message/6306#6306

it was actually my idea to for the oci8 stuff - and have some new 
maintainer maintain it in pecl.

i see no valid reason against it. he can start hacking on it (in pecl) 
starting today - once he is comfortable with it we'll nuke the ext/oci 
and use(link, package) the stuff from pecl.

loosing all history for the 2 files is not a deal at all if you ask me, 
as not much has happened to teh code in the last many month.

why do we manage to make a big deal out of everything?

if we get a new maintainer, i'd like him to be able to roll independent 
from the main-tree. (also - don't forget - not too many ppls use 
oracle, and those who do would be more than happy to get new 
features/improvemnt from a new maintainer)


thies

---

## #6309 — Wez Furlong — 2003-12-09T19:57:52+00:00

URL: https://externals.io/message/6306#6309 · In reply to: #6306

> it was actually my idea to for the oci8 stuff - and have some new 
> maintainer maintain it in pecl.

Yep, I remember.
 
> i see no valid reason against it. he can start hacking on it (in pecl) 
> starting today - once he is comfortable with it we'll nuke the ext/oci 
> and use(link, package) the stuff from pecl.

We can go a little bit further than that; lets move it properly in
CVS and roll a pecl release (1.0), and then Tony can continue
his work in the way that pecl is supposed to be working.
 
> loosing all history for the 2 files is not a deal at all if you ask me, 
> as not much has happened to teh code in the last many month.
 
> why do we manage to make a big deal out of everything?

I agree; I was surprised that it hadn't actually been
moved properly, but thought that someone else had handled
that (along the same lines as the surprise appearance of
pecl/perl today).
 
> if we get a new maintainer, i'd like him to be able to roll independent 
> from the main-tree. (also - don't forget - not too many ppls use 
> oracle, and those who do would be more than happy to get new 
> features/improvemnt from a new maintainer)

This is precisely what I want to encourage in PECL.

--Wez.

---

## #6310 — Pierre-Alain Joye — 2003-12-09T20:09:09+00:00

URL: https://externals.io/message/6306#6310 · In reply to: #6309

On Tue, 9 Dec 2003 19:57:52 -0000
"Wez Furlong" <wez@thebrainroom.com> wrote:

> > […]
> 
> This is precisely what I want to encourage in PECL.

Fully aggreed (if that count ;) ). I really like the idea to work on
package release basis in preference of "horrible" CVS tags ;).

pierre

---

## #6311 — Derick Rethans — 2003-12-09T20:12:44+00:00

URL: https://externals.io/message/6306#6311 · In reply to: #6310

> On Tue, 9 Dec 2003 19:57:52 -0000
> "Wez Furlong" <wez@thebrainroom.com> wrote:
>
> > […]
>
> Fully aggreed (if that count ;) ). I really like the idea to work on
> package release basis in preference of "horrible" CVS tags ;).

For this to work pear install <pecl package> needs to work first.
Try "pear install tidy" -> doesn't work, while "pear download tidy"
works fine. And as the pear installer has as much docs as the Zend
engine... I've no time/clue on where to start looking for the problem
;-)

Derick

---

## #6312 — Pierre-Alain Joye — 2003-12-09T20:16:20+00:00

URL: https://externals.io/message/6306#6312 · In reply to: #6311

On Tue, 9 Dec 2003 21:12:44 +0100 (CET)
Derick Rethans <derick@php.net> wrote:

> 
> 
> > […]
> 
> For this to work pear install <pecl package> needs to work first.

Tomas and I asked many times the help of internals guys and posted a RFC
for binary packages :). But I missed the install error, damnit :P

> Try "pear install tidy" -> doesn't work, while "pear download tidy"
> works fine.

http://pear.php.net/bugs/ is a good start :-D


> And as the pear installer has as much docs as the Zend
> engine... I've no time/clue on where to start looking for the problem
> ;-)

docs? what's that?

pierre

---

## #6314 — Jani Taskinen — 2003-12-09T20:21:57+00:00

URL: https://externals.io/message/6306#6314 · In reply to: #6309

> > […]
>
>Yep, I remember.
> 
> > […]
>
>We can go a little bit further than that; lets move it properly in
>CVS and roll a pecl release (1.0), and then Tony can continue
>his work in the way that pecl is supposed to be working.

    And you're moving us into the support nightmare..
    Instead of asking what php version they use, we need
    to start asking which possible versions of different
    extensions they happen to use, how they compiled them,
    etc. etc. etc.
    
    Thanks, but no thanks. Keep PECL as sibe...for the not-so-golden
    exts and the rest in php-src.
    
    --Jani

---

## #6315 — Wez Furlong — 2003-12-09T20:24:07+00:00

URL: https://externals.io/message/6306#6315 · In reply to: #6314

>     And you're moving us into the support nightmare..
>     Instead of asking what php version they use, we need
>     to start asking which possible versions of different
>     extensions they happen to use, how they compiled them,
>     etc. etc. etc.

The flip side is that we can provide them with a "localized"
(not in the i18n sense!) fix much sooner.

This isn't really a problem as you tend to mark all bug
reports as bogus anyway, and no one else provides support.
     
>     Thanks, but no thanks. Keep PECL as sibe...for the not-so-golden
>     exts and the rest in php-src.

More FUD.

--Wez.

---

## #6316 — Jani Taskinen — 2003-12-09T20:28:29+00:00

URL: https://externals.io/message/6306#6316 · In reply to: #6315

> > […]
>
>The flip side is that we can provide them with a "localized"
>(not in the i18n sense!) fix much sooner.
>
>This isn't really a problem as you tend to mark all bug
>reports as bogus anyway, and no one else provides support.

    Sorry, I forgot, of course the relevant bug categories will
    also be moved to http://pecl.php.net/bugs/.

    FYI: I don't mark all bug reports as bogus. Only those that are..:)
    
    --Jani

---

## #6317 — Wez Furlong — 2003-12-09T20:31:31+00:00

URL: https://externals.io/message/6306#6317 · In reply to: #6316

> > […]
> 
>     Sorry, I forgot, of course the relevant bug categories will
>     also be moved to http://pecl.php.net/bugs/.
> 
>     FYI: I don't mark all bug reports as bogus. Only those that are..:)

Everybody will be happy with PECL then :-)

--Wez.

---

## #6318 — Ilia Alshanetsky — 2003-12-09T20:53:39+00:00

URL: https://externals.io/message/6306#6318 · In reply to: #6315

> The flip side is that we can provide them with a "localized"
> (not in the i18n sense!) fix much sooner.

The current snapshot system contains a patched version (after the fix is 
applied) within 2 hours at most for source distributions and 4 hours for 
win32 distributions.

> This isn't really a problem as you tend to mark all bug
> reports as bogus anyway, and no one else provides support.

I beg to differ, there are plenty of people (not to say that there couldn't be 
more ;) ) who handle bugs etc... you need to look no further then the NEWS 
file.

I may have misunderstood you, so please correct me if I am wrong, but it seems 
are you advocating a system where by modules are compiled as shared. This 
approach would open a whole can of worms with users using conflicting module 
versions, trying to load same modules more then once and so on. Not only will 
this be a headache for the users, but also for the QA/developers who wish to 
solve user reported problems. Without a way to determine the exact version of 
the module it'd be nearly impossible to determine what code is the user 
actually using.

Ilia

---

## #6319 — Pierre-Alain Joye — 2003-12-09T20:56:35+00:00

URL: https://externals.io/message/6306#6319 · In reply to: #6311

On Tue, 9 Dec 2003 21:12:44 +0100 (CET)
Derick Rethans <derick@php.net> wrote:

> 
> 
> > […]
> 
> For this to work pear install <pecl package> needs to work first.
> Try "pear install tidy" -> doesn't work, while "pear download tidy"
> works fine. And as the pear installer has as much docs as the Zend
> engine... I've no time/clue on where to start looking for the problem
> ;-)

Copy the file php-src/pear/PEAR/Downloader.php to
{pearprefix}/PEAR/Downloader.php.

That should fix this bug until the next release.

hth

pierre

---

## #6321 — Wez Furlong — 2003-12-09T21:05:55+00:00

URL: https://externals.io/message/6306#6321 · In reply to: #6318

> > […]
>
> The current snapshot system contains a patched version (after the fix is
> applied) within 2 hours at most for source distributions and 4 hours for
> win32 distributions.

By localized I meant that only the part of the code that the user
was worried about gets the fix; quite often, people don't even want
to try our stable snapshots in case they introduce more bugs.

> > […]
>
> I beg to differ, there are plenty of people (not to say that there
couldn't be
> more ;) ) who handle bugs etc... you need to look no further then the NEWS
> file.
>
> I may have misunderstood you, so please correct me if I am wrong.

I was using Jani's own brand of humour; I do know just how much
work goes into bug fixing (I've spent many hours of my own time
there too, even though I've not been so prolific in that department
recently).

> but it seems
> are you advocating a system where by modules are compiled as shared.

If the person making the installation wishes it, they can do that now.
I am not advocating a change in our default installation.

> This
> approach would open a whole can of worms with users using conflicting
module
> versions, trying to load same modules more then once and so on.

We have that now; it happens rarely (although more often on windows).

> Not only will
> this be a headache for the users, but also for the QA/developers who wish
to
> solve user reported problems. Without a way to determine the exact version
of
> the module it'd be nearly impossible to determine what code is the user
> actually using.

Modules have a version field, and the pear/pecl installer keeps track
of the installed version.

None of these problems are insurmountable, nor are they terrible, and
none of them will affect anyone doing a default install.

If we worry about everything that might possibly make things slightly
harder to debug, then we shouldn't make any changes to the code, write
no more new features and fix bugs for the rest of eternity.

--Wez.

---

## #6320 — Derick Rethans — 2003-12-09T21:06:27+00:00

URL: https://externals.io/message/6306#6320 · In reply to: #6319

> > […]
>
> Copy the file php-src/pear/PEAR/Downloader.php to
> {pearprefix}/PEAR/Downloader.php.
>
> That should fix this bug until the next release.

How would that help when Downloader.php is not even used?:

derick@kossu:/usr/local/lib/php$ grep -r Downloader *
derick@kossu:/usr/local/lib/php$


Derick

---

## #6326 — Stig S. Bakken — 2003-12-10T07:11:07+00:00

URL: https://externals.io/message/6306#6326 · In reply to: #6314

> 
> 
> > […]
> 
>     And you're moving us into the support nightmare..
>     Instead of asking what php version they use, we need
>     to start asking which possible versions of different
>     extensions they happen to use, how they compiled them,
>     etc. etc. etc.
>     
>     Thanks, but no thanks. Keep PECL as sibe...for the not-so-golden
>     exts and the rest in php-src.

We know which releases of which (pecl) extensions are bundled with each
PHP release.  But to meet this problem, we should ask people to attach a
dump of `phpinfo()` or phpinfo("extname") and make sure that contains the
necessary information.  At the very least, the extension version number
should be in there, preferably added automatically.  There's a field for
version number in the extension struct.  I recall you supporting me
whole-heartedly on the very same issue back in the 4.1.0 days when the
version info was added, remember?

How people compile the extensions should be clear from that also, at
least just as clear as it is today.

 - Stig

---

## #6327 — Stig S. Bakken — 2003-12-10T07:12:38+00:00

URL: https://externals.io/message/6306#6327 · In reply to: #6315

> > […]
> 
> The flip side is that we can provide them with a "localized"
> (not in the i18n sense!) fix much sooner.
> 
> This isn't really a problem as you tend to mark all bug
> reports as bogus anyway, and no one else provides support.

IMHO moving extensions to PECL would improve the extension maintainer's
ability to provide support, just because he is able to roll patchlevel
releases only with bug fixes.
     
 - Stig