Package home | Report new bug | New search | Development Roadmap Status: Open | Feedback | All | Closed Since Version 0.3.0

Bug #9932 cannot build specs from external channels
Submitted: 2007-01-24 09:25 UTC
From: judas dot iscariote at gmail dot com Assigned: cellog
Status: Closed Package: PEAR_Command_Packaging (version 0.1.2)
PHP Version: 5_2 CVS-2007-01-24 OS: irrelevant
Roadmaps: 0.2.0    
Subscription  
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes. If this is not your bug, you can add a comment by following this link. If this is your bug, but you forgot your password, you can retrieve your password here.
Password:
Status:
2007-03-04 11:21 UTC
Package:
Bug Type:
Summary:
From: judas dot iscariote at gmail dot com
New email:
PHP Version: Package Version: OS:

 

 [2007-01-24 09:25 UTC] judas dot iscariote at gmail dot com (Cristian Rodriguez)
Description: ------------ Seems this tool cannot be used to build spec files from non pear.php.net packages Test script: --------------- pear channel-discover pear.symfony-project.com pear download symfony/symfony-beta pear make-rpm-spec symfony-1.0.0beta4.tgz ( you can choose other PEAR servers, as ez.no ones, result is the same) Expected result: ---------------- spec file built with a post install check to add the channel into the rpm user installation in case it is not yet there. Actual result: -------------- Adding package pear.symfony-project.com/symfony to registry failed

Comments

 [2007-01-24 09:54 UTC] timj at php dot net (Tim Jackson)
I agree that this doesn't work. With PEAR 1.4.9, I seem to get: $ pear -c pearrc make-rpm-spec symfony-1.0.0beta4.tgz commit failed Actually most (though probably not all) of the code is there in make-rpm-spec to handle channels, though I've never actually had the cause to use/test it. However both the error you got and the one I got are coming from PEAR core, not PEAR_Command_Packaging, which is interesting. This doesn't mean that it's not a bug in PEAR_Command_Packaging (though it might not be) but it's something more than superficial I think.
 [2007-01-24 14:48 UTC] cellog (Greg Beaver)
please try with PEAR 1.5.0, which was released yesterday
 [2007-01-24 15:14 UTC] timj at php dot net (Tim Jackson)
I erred in my previous comment; that was actually a test with 1.5.0. Reproduced from a clean PEAR install in a temp directory: $ pear -c pearrc list Installed packages, channel pear.php.net: ========================================= Package Version State Archive_Tar 1.3.2 stable Console_Getopt 1.2.1 stable PEAR 1.5.0 stable PEAR_Command_Packaging 0.1.2 alpha $ pear -c pearrc make-rpm-spec symfony-1.0.0beta4.tgz commit failed I haven't done a proper backtrace yet but I'm guessing the call to PEAR core is coming via the $installer->install() call on line 200 of Packaging.php.
 [2007-01-24 15:21 UTC] cellog (Greg Beaver)
and does your local install know anything about the symfony channel? It is looking like the error handling in PEAR_Command_Packaging isn't displaying what is actually happening pear -c pearrc list-channels
 [2007-01-24 15:32 UTC] timj at php dot net (Tim Jackson)
Yes it does. $ pear -c pearrc list-channels Registered Channels: ==================== Channel Summary pear.php.net PHP Extension and Application Repository pear.symfony-project.com symfony project PEAR channel pecl.php.net PHP Extension Community Library __uri Pseudo-channel for static packages I agree that whatever the cause of this, the error reporting is not all that helpful :)
 [2007-01-24 16:03 UTC] timj at php dot net (Tim Jackson)
OK, the call is definitely coming via line 200 of PCP. I'm not sure what PCP should be doing here though re: error handling; it doesn't get another chance to handle the error as it never gets another look-in past the $installer->install() in line 200; an error ("commit failed") gets thrown in line 1293 of PEAR/Installer.php and that's the end of it.
 [2007-02-18 04:27 UTC] cellog (Greg Beaver)
PEAR_Command_Packaging is using 'installroot' instead of 'packagingroot' in its code. Use packagingroot and all will work just fine. If you use installroot, PEAR will set up the registry as if you were going to install the package into /tmp/fw8fu9ue or whatever it makes. This will mean that uninstallation won't work because the absolute path locations will all be wrong on the final user system. Uncovered another bug in the process, I'll open with a patch
 [2007-02-18 04:34 UTC] cellog (Greg Beaver)
This bug has been fixed in CVS. If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET). If this was a problem with the pear.php.net website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better. I'll just fix both bugs and close them
 [2007-02-21 23:07 UTC] timj at php dot net (Tim Jackson)
What was the related bug you discovered?
 [2007-02-22 04:50 UTC] judas dot iscariote at gmail dot com
I also found other problem related to this. now you can create the spec file, but 1. rpm wont build, since the external channel is not registered. 2. if I download channel.xml and pear channel-add channel.xml it works but only as root, and in real-life rpm buildhosts you cannot build stuff as root.the error seems to existe in Pear's Registry.php where ".lock" files are always created in 'phpdir'.
 [2007-02-22 05:07 UTC] cellog (Greg Beaver)
please open up a separate bug, this is an .rpm installation issue, not a packaging issue (subtle distinction, but I like to keep bugs separate, makes it easier to link CVS commits to the bug report). The only solution is to download the channel.xml and to include the channel-add directly in the .rpm Frankly, if the .rpm can install the package, it will be able to channel-add, so the question of root vs. non-root is a non-issue, as long as the channel-add happens in the .rpm itself.
 [2007-03-04 11:21 UTC] timj at php dot net (Tim Jackson)
The further problems in actually building an RPM for a package from an external channel are discussed in bug #10254.