This is a temp fix for the pecl issue we have on gentoo (libtool mismatch) hopefully someone can make it better, and package it as part of the php ebuild Reproducible: Always Steps to Reproduce: #!/bin/bash lib=$1 #the libs name getit=$(wget http://pecl.php.net/get/$1) #now download the lib move=$(mv $1 $1.tgz) #move the file since it doesnt have an extension extract=$(unfoo $1.tgz); remove=$(rm $1.tgz package.xml) #remove the file nad its package.xml filename=$(ls | awk -F / '{ print $1 }') cd $filename #move to the folder #now actually do the stuff in order to make it phpize aclocal libtoolize --force autoheader autoconf configit=$(sh configure) make make install cd ../ remove=$(rm -rf $filename)
I'm sure someone doing PHP knows what the "Gentoo PECL issue" is.
I have no idea what that is supposed to fix. Nor how that install procedure is different from how we already install PHP extensions. We phpize, run eautoreconf and so on. Need more information here.
this isnt to solve the problem of pecl-<lib> problems the ones that are already in portage are fine, the problem is ones that arent, if you try and run "pecl install <lib>" you will most likelly get the libtool mismatch error, and this is the solution to that issue (but in a single script instead of having todo the process manually)
I see ... Creating a pecl ebuild is pretty much straightforward. Just a matter of creating an ebuild with the name of the pecl package prefixed with pecl- and then inheriting php-ext-pecl-r1. What is the reason you want to install something directly through the pecl command?
mainly due to not wanting to build an ebuild for every pecl lib, so for instance if someone makes a lib that is released on friday, that is then retired on sunday, but someone in 2 years thinks they want that lib, expecting someone to build an ebuild for it, is asking too much really (if no other reason than on (most) other dists you can just run the "pecl install <lib>" command without any issues) at least this way if it was released as gentoo-pecl or something, (and also added the lib to the pecl library so that "pecl remove <lib>" could work) then at least if nothing else PECL could have a special instruction Generic Linux: pecl install <lib> Gentoo Linux: gentoo-pecl install <lib> instead of having to tell people Generic Linux: pecl install <lib> Gentoo Linux: nano/vi /etc/portage/packages/pecl/pecl-<lib> ....
I'm afraid the difficulties you face are by design. Rebuilding everything from source (and touching it in the process) means we got to use our system's libtool instead of the one upstream used. Ole is already working on getting what you want for PEAR, maybe when that's done we can do the same for pecl. No promises though, at the moment it's just the two of us and core PHP is already taking much of the time we can spend. That said - making gentoo-pecl a shell script that makes an ebuild (using a template and inheriting php-ext-pecl-r{1,2}) and emerges it should be doable. Not sure I'd *want* such a thing, as the ebuild may apply patches, specify other configure parameters and all...
thats the main reason i went down this path, that way its easy to issue an instruction for people with the libtool issue, so that they can install the package without any major issues, the biggest hurdle that i can see is that it doesnt then get added to the pecl-install-library so doing pecl remove <lib> doesnt work if we can get that working, from the point of view that is a general user, there is no restriction, true from the repos point of view this is not the ideal solution, but its a shortstop till a better solution is found, and due to it being a bundled script, changing its logic later is not an issue, since the run command would be the same, but the actual internal process would have changed to a better method (In reply to comment #6) > I'm afraid the difficulties you face are by design. Rebuilding everything from > source (and touching it in the process) means we got to use our system's > libtool instead of the one upstream used. > > Ole is already working on getting what you want for PEAR, maybe when that's > done we can do the same for pecl. No promises though, at the moment it's just > the two of us and core PHP is already taking much of the time we can spend. > > That said - making gentoo-pecl a shell script that makes an ebuild (using a > template and inheriting php-ext-pecl-r{1,2}) and emerges it should be doable. > Not sure I'd *want* such a thing, as the ebuild may apply patches, specify > other configure parameters and all... >
(In reply to comment #6) > > Ole is already working on getting what you want for PEAR, maybe when that's > done we can do the same for pecl. No promises though, at the moment it's just > the two of us and core PHP is already taking much of the time we can spend. > > That said - making gentoo-pecl a shell script that makes an ebuild (using a > template and inheriting php-ext-pecl-r{1,2}) and emerges it should be doable. > Not sure I'd *want* such a thing, as the ebuild may apply patches, specify > other configure parameters and all... > There is an issue with handling dependencies and whatnot here. Installing stuff outside of the tree and expecting it to work with packages within the tree is rather impossible to accomplish. If you like, I can publish your script on planet.gentoo.org, but then with a warning that Gentoo will in no way support any use of it. If you want to use any pecl extension on Gentoo, I recommend you file a bug about getting an ebuild created. In most cases it will only take a week or so before it gets added to the tree. I am closing this as wontfix, as I see no way Gentoo can offer support on installing pecl packages outside of ebuilds.
