Description: ------------ While fixing bug #8630 it came to light that PCP does not currently handle <install as="xx" name="yy" /> constructions; this will stop the RPM from building (because the %files list does not correspond to where the temporary installation actually took place). This is probably either very easy or very difficult to fix; it may require complete rewriting of how the file list generation happens, or maybe there's an easy way to internally retrieve the *real* destination (after "install as") from PEAR_PackageFile or something.

I haven't fully thought this through, but one possible (relatively simple) solution may be to iterate over the list of actual installed files in the temporary installation which is done during the packaging process, rather than iterating over the file list obtained from PEAR_PackageFile. This will definitely give us the final install locations! We will lose the role information along the way, but that doesn't really matter too much, since RPM doesn't know about that anyway - it's just interested in where things end up. This is possibly something that could be part of v0.2.x refactoring.

There is another bug related to this but with the same fix. The logic for generating prefixes in PCP is wrong; it duplicates some of the logic from PEAR itself and doesn't get it quite right. This is shown by @files@ sometimes missing path elements, for example building Console_Color results in: /path/to/pear/Color.php instead of /path/to/pear/Console/Color.php This is certainly present in 0.1.2 and from the code has probably always been the case. The common fix for both problems is now in CVS and is to allow PEAR itself to figure out the final file location and then use the "installed_as" property from PackageFile when generating the file lists for the RPM.