Re: [RFC] PECL binary creation and distribution

Wez Furlong wrote:

package creation ---------------- pear package [-t <type>] <package>

There was some talk of moving the package creation stuff to a separate tool from the pear command. If that is the case, "pecl-package [-t <type>] <package>" might be the actual syntax.

Umm, yeah better so. This way we could unbloat the PEAR package. I also have the idea to create a peardev command, and move there the commands not used by non-developers (package, cvstag, etc). So, what about having sepparate packages: PEAR, PEAR-Dev, PECL-Dev. I could isolate the build stuff from the PEAR package and create for you a preliminary PECL-Dev package for hacking. For the records, I'd preffer to have the same command for building packages, both PEAR and PECL.

Additionally of generating the native package description file, we could perhaps also call the tools for generating the whole

package. I'm not quite sure what you mean here. You mean, generate all the various binary packages when generating the native pear package?

Nowadays, if you do a "pear rpmbuild foo" it will just generate a foo.spec file. What I meant was that it could directly create the rpm with the command "pecl-package -t rpm foo" and generate just the spec with "pecl-package -t rpm --only-native-package-info-file foo" (feel free to choose a shorter param name ;). The same for msi for example.

An idea would be to create in addition a BUILDINFO.txt file with some data

about

the env where the extension was compiled at, like the php version, the php_uname(), the extra libs versions, os vendor version, pear version, etc.

Dependency information for extra libs is useful, but if the packaging is done correctly, it will either: - Be targeted for a specific platform and set of libraries (eg: Red Hat 7.3 always has libfoo version x.y installed, so packages for that platform will always work). - Include the required libraries (if they are hard to find, compile or install) - Statically link the libraries (again, if they are hard to find, compile or install). Of course, just listing the requirements in one place will be helpful - don't we have a section for that in the package.xml?

Yes, that's what we call dependencies, including dependency check on: other package, external prog, OS, sapi, php version, lib, external programm, etc. Take a look at php-src/pear/PEAR/Dependency.php. My idea with the BUILDINFO.txt file, was when you get a problem compiling an extension, you could read that file and try to adapt your system to the libs the original developer used.

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.

package.xml ----------- As a binary release shares the same release data with the source distrib, the same package.xml file could be used for all kind of distribs. Let's say something like: <release>

        <version>...
        <date>
        <notes>
        <filelist>..
           <file role="ext" platform="">
        </filelist>

</release> A package may contain many compiled extensions for different platforms, one single extension or the sources.

I like this idea. I was discussing packaging with someone by private mail and they suggested that once you start creating binary packages, you end up having to create a whole bunch for the various different systems out there. In order to avoid agony during the release process, the author/publisher of the extension will only want to upload a single file to the pecl site. So, what would be nice would be to expand your idea above so that the package.xml can contain references to the source and each generated binary package. This info would create a native pear .tgz containing all these things. The author would upload that file, and the server would split it into a source package and a bunch of binary arch-specific packages. It probably won't end up working exactly like this, but thats the general idea.

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.

Installation ------------ pear install -t bin peclfoo (download and install the binary distrib of peclfoo for your current OS-ARCH) pear install peclfoo (download, build and install peclfoo)

I think that installing the binary package (when available) should be the default for win32. For other systems, we might want to use some intelligence about package selection. For example, if the system is rpm based, and there is an rpm for the package available, and the package is currently uninstalled, or is installed as an rpm for a previous version of the package, download and upgrade to the new rpm.

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: Win32: c:> pear install peclfoo Downloading: peclfoo-win-i386-2.3.tgz Install: ok 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). 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 $ pear install peclfoo No binary package ... (the same as above)

Listing in the web ------------------ A new column "Type" should be added to the release listing under the package home page at pear.php.net, saying that the package is a binary distrib compiled for OS X and ARCH Y or sources.

In addition, we need to tweak the database to that we can add "links" to packages hosted on external sites. The installation tool would query the data from the pecl site, which would then redirect requests for that package to the actual source.

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 Tomas V.V.Cox