Re: Re: [RFC] PECL binary creation and distribution

Wez Furlong wrote:

Thomas V.V. Cox said:

An important thing that Sara mentioned was licensing - if the package is

not

licensed under the PHP license, we should probably have some kind of annoying thing that displays the license just prior to installation.

Np. Give to me the texts and the cases when you need to display them and I'll take care on adding them.

That needs someone to read the major licenses and see what the requirements are. Basically, if its the PHP license, we needn't do anything more. For BSD style licenses with advertisement clauses, we should probably display the required advertisement (this should probably have an entry in the package.xml). For the GPL style licenses, we should probably display a couple of lines that inform the user of their rights to the source code, and the worlds rights to their source when they use it ;)

Let's wait for "Some One" then.

IMO is a bad idea to relay in a external site out of the pecl site. I'd strongly recommend to the originally author to upload bin packages to the pecl web. In a short time I'd create the new "pear publish" command, for submitting packages to the web. This way you can automate this task

easily. One of the key things that will make PECL successful is to make it *the* definitive place to find out about all the PHP extensions out there.

Well, IMHO the key for success would be if the PECL extensions could contain quality verified extensions, not just all the crap arround that could make your web server segfaulty. At least something like "PECL QA Approved" logo would be cool.

I'd like PECL to be something like a cross between freshmeat and what we have now in PEAR, but focused on PHP extensions only.

Hostcripts->PECL? ;)

How about a compromize - when a package is stored on an external site, why not do something like this: -------------------------- # pear install acme-enterprise-foo acme-enterprise-foo is not stored in the central PECL repository. You can download it from <Author/Manufacturer Name> by typing: # pear install --redirect-external acme-enterprise-foo Remember to contact <Author/Manufacturer Name> if you experience problems with the package, as it is not maintained by the general PECL community. -------------------------- Any other suggestions?

Yes. One of the visions is to provide support for "channels" (ala redcarpet). With them people could download and install packages out the PEAR or PECL scope, even both will become channels. That would avoid package name conflicts. It'd look like: $ pear install pecl:sqlite $ pear install pear:xml_parser If you want to list channels out of PECL, you could just do it by publishing a list of "PECL friendly" channels, users could easily subscribe to.

I don't really like this idea, but it's up to you :-). I'd preffer to default the installation of a pecl extension to bin. Perhaps a "preffered bin type" setting would make sense). User cases:

Defaulting to binary on unix scares me a little ;)

c:> pear install peclbar No binary package for Windows i386. In order to install this extension you need to build it from sources. Install the PECL-Dev package (pear install PECL-Dev) and issue the command "pecl-package peclbar" (you'll need a compiler and blah blah).

Its a bit more difficult than that unfortunately :/ I have some ideas for the win32 build that might solve this, but really lack the time to make it work - it can wait for a while anyway.

Linux: $ pear install peclfoo Downloading: peclfoo-linux-i386-2.3.tgz Install: ok or: $ pear install -t rpm peclfoo Downloading: peclfoo-linux-i386-2.3.rpm Running: rpm -Uvh peclfoo-linux-i386-2.3.rpm Install: ok or: $ pear config-set preffered-bin-type rpm $ pear install peclfoo Downloading: peclfoo-linux-i386-2.3.rpm Running: rpm -Uvh peclfoo-linux-i386-2.3.rpm Install: ok

OK, but what about when they want to upgrade? What if there is (for whatever reason) no rpm available for the upgrade? Or perhaps they choose a beta to be built from source ? The installer should be smart enough to know if an rpm version is installed and handle it correctly, or at least give the user instructions on how to handle it manually. Maybe I'm thinking too hard ;)

Looks like we need an abstraction layer for package managers :-D

In general, what you've said is good - if we can set these defaults appropriately at the time the pear/pecl infrastructure is installed, then it will probably work well enough for most people. This would be during ./configure time for php. ./configure --enable-preferred-package-type=rpm and have sensible defaults for when the option is omitted.

Well, this can be even more easy. For the first installation: $ pear install peclfoo Oops no preffered-bin-package-type set, use blah blah help here $ pear config-set prefered-bin-package-type (src*|bin|rpm|msi) *) src -> download, compile, install One could override this setting by the "-t" option to "pear install".

As I said I don't like the idea of relaying in external sites. There is already a "Package Home Page" link see an example of an external hosted package: http://pear.php.net/package-info.php?package=PhpDocumentor

To me, the packages appear to be hosted in pear. Is this not the case?

Sorry, I meant a "external hosted development", this is, they have their own cvs, web, etc. and they just publish releases under the PEAR site. Tomas V.V.Cox