Re: [RFC] PECL binary creation and distribution

> 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. > 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? > 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? 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. > 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. > 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. > 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. --Wez.