Re: official docs for package.xml 2.0 will be on pear.php.net tomorrow

> That's a neat idea. My only concern with your suggestion is the > security of allowing arbitrary code execution, considering that channels > allow anybody to set up a channel server. Some shmuck might distribute > hostile code through PHP in the midst of "checking" dependencies. I > moved post-install scripts outside of automatically running during > installation for that reason. > Good call. But this isn't entirely different from the idea of someome putting rm -rf / into a make all target in a more traditional source tarball. (My long standing nightmare scenario) Perhaps instead of allowing alternate shells we keep it to php-cli only *and* design the pear installer to always turn on safe mode and other restrictions during test phase. Maybe show a prompt: "This package would like to execute some PHP code to test the suitability of your environment: (A)llow test to run, (S)kip test and assume requirements are met, (D)isplay code to be run and prompt again, (Q)uit and abort installation." (No I didn't mean for those to all be next to each other on the keyboard) > I wonder if it would be enough for your needs to implement something > like an <or> tag and perhaps a <set> tag? > Funny you should mention that. That option was actually in my original post before being snipped out for brevity. For this particular example it absolutely would work fine, but I wouldn't doubt there are more complex situations not yet appearant. Let's say an imaginary pear class File_AES requires the mcrypt extension and that libmcrypt was compiled for aes/cbc support. How do you check the second half of that requirement without being able to run mcryp_module_open('rijndael-256','','cbc','') and testing for !== false? Again, just an example, I can make tougher ones if you'd like :) How about requiring that one (but not both) of a pair of extensions be available. Not sure when that'd ACTUALLY be a requirement, but nay saying is so much easier than constructive comments. > Unfortunately, this would result in some serious complexity. I don't > know if you've been following pear-dev, but devs are complaining because > PEAR 1.4 is weighing in at about 8-15 MB per run depending on what > you're doing with it. Supporting this syntax would add another MB or > so, I would imagine. > No I havn't been following. My personal bandwidth these days gets slimmer and slimmer. The footprint issue is a definite problem... Have all y'all pear guys considered turning PEAR itself into a pecl extension instead? . . . . . . OKAY! OKAY! I WAS JUST KIDDING! > I'm open to other ideas. Maybe a feature dependency, with types > <stream>, <function>, <class>? > That has possibility. I will say that (going back to the File_AES example above), if one were looking for the mcrypt.rijndael-256 filter exposed by the mcrypt_filter extension. Checking for <filter>mcrypt.rijndael-256</filter> couldn't be cleanly done in userspace as the extension only exports mcrypt.* as a filter factory which dynamicly tries to load one mcrypt module or the other depending on what name is actually passed. At best PEAR could attempt to do: $ok = stream_filter_append(STDOUT, $filtername); if ($ok) { /* req passed */ stream_filter_remove($ok); } else { /* req failed */ } but that approach has two problems. #1 It assumes the availabiltiy of stream_filter_remove which is PHP >= 5.1 only. #2 It assumes no filter parameters are required (as it happens, mcyrpt.* fitlers require an array with iv and key elements). But of course I'm poking out worst case scenarios here, in the 99% of cases, that schema sounds very usable. > <stream>zlib.inflate</stream> > But if I may be allowed one more fussiness... Rather than <stream> there should be separate <wrapper> <filter> and <transport> "features". Speaking of which, <transport>ssl</transport> would be a much more comprehensive approach to making sure that ssl:// socket capability existed than requiring <extension>openssl</extension> since in PHP < 5 having openssl loaded as a module doesn't actually provide the ssl transport. Of course, userspace can't enum transports prior to PHP 5 anyway. Refresh my memory, is there a way to tell if a module is shared/static from userspace? This is all probably making mountains out of mole hills. Those 1% of packages/extensions which require funky dependencies can probably be dealt with through documentation far more easily. -Sara