Re: structure of PEAR .tgz for PEAR 2 - IMPORTANT CHANGES SUGGESTED IN HERE

On 12/29/06, Greg Beaver <greg@chiaraquartet.net> wrote:

Hi all, Currently, when you package up a PEAR package, it creates this file structure inside the tar: Assume we're packaging PEAR version 1.5.0 package.xml PEAR-1.5.0/

           docs/whatever
           PEAR/file.php

When installed, we get: docs/PEAR/whatever PEAR/file.php This means that for obvious reasons a PEAR-packaged .tgz can only really be installed by the PEAR Installer unless the developer goes to great lengths to make it possible to run out of the .tgz as PhpDocumentor does. I don't really see any compelling reason to keep this structure, especially as it prevents any easy way to extract an archive and then convert it into a PEAR installation. If the internal tar file structure were instead: pear.php.net!PEAR-1.5.0-package.xml docs/PEAR/whatever PEAR/file.php This would in fact match the way that PEAR stores the files in the registry, meaning that converting this into an upgradeable PEAR registry would be a simple task. However, this would break backwards compatibility with the PEAR Installer. Since there is obviously no overlap, it is conceivable that folks worried about supporting both versions could in fact distribute an archive combining the two formats (and this could easily be supported inside PEAR2). This doubles the size of an archive, which is different from distributing a package2.xml. These changes would make it far easier to start out by simply unzipping a PEAR package (or several PEAR packages), and then later moving to the PEAR Installer. In fact, it would also allow people to bundle PEAR packages inside their source tree, and later upgrade the packages inside the source tree with their own repository - it's a huge advance, if this technical/political hurdle can be overcome. Obviously, the technical stuff is easy (I just suggested the solution), the question is whether the technical solution is politically palatable to all of you :). This doesn't really affect PECL. PECL extensions are always compiled in temporary directories and then moved, and binary packages are moved to the extension directory.

Sounds like a good idea to me. -- Justin Patrin