[prev in list] [next in list] [prev in thread] [next in thread] 

List:       pecl-dev
Subject:    Re: [RFC] PECL binary creation and distribution
From:       "Tomas V.V.Cox" <cox () idecnet ! com>
Date:       2003-09-22 7:25:10
[Download RAW message or body]

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

[prev in list] [next in list] [prev in thread] [next in thread]