Jyri Virkki wrote: > UNIX admin wrote: > >> For my part, I would very much like to see php be available as /usr/bin/php. >> >> What is the final consensus on this matter? >> > > No formal consensus, but I filed an RFE to track the change. When > someone gets to making the code changes and posts the code review, > it'll probably be approved. It should get recorded in a relevant ARC > case as well, though I don't really expect opposition there either. > There's a lot of process for seemingly simple changes, which is why > the answer to "final consensus" isn't so straighforward... But I > wouldn't expect adding this to be a problem, just a matter of doing it. > > > >> In my experience, for PHP, making a distinction between "php4" and >> "php5" is enough. >> > > Good to hear. > > >> With this in mind, I propose that the packages be renamed before >> Nevada is solidified into the next release of Solaris. Current >> naming is "SUNWphp520", whereas in my experience "SUNWphp5r" and >> "SUNWphp5u" would have been just fine (and elegant). >> > > At the very least I'd like to see it versioned at the "5.2" (5.2.*) > level, but if versioning it as 5 (5.*.*) is possible, that would be > ideal. I didn't use PHP prior to php5 so I can't comment on enough of > its compatibility history but I'd like to hear from others here who've > used it long enough so we can gather enough data to go one way or the > other. >
Of course, the challenge here is that if we did drop the micro, or even the minor and there was an incompatible change significant enough we'd be breaking other people's code, we would find it harder to deliver the micro release through a patch though. Other options would be to to fork or reintroduce the more explicitly versioned path. The point here is there is no control over when there is an incompatibility introduced. Perhaps there's a good middle ground here somewhere? I read up on a bunch of the ARC cases when Stefan originally started the PHP update, and there was some discussion of how Java does things now. It seemed no one was really happy with the symlinks in /usr/jdk, but I have to say it does make it clear from a user perspective. I guess the ipkg approach would allow people to hold their PHP at a given minor release without changing the rest of OpenSolaris, but that's still at least a few months out. :) I don't know yet if it would mean, for instance, someone could install OpenSolaris 12/09 and get the PHP that was around back in 06/08. If they could (even in an 'unsupported' fashion), then that would be a good thing since the monolithic approach we have right now would be broken up. Presumably the opposite would be possible.... but I don't know. Could I keep my OpenSolaris held back to 06/08 (if say, it weren't mine but I was just using shared infrastructure) and I wanted the 12/09 PHP? I'm thinking about all of this in part because I just spent some time with a user who is stuck on PHP 4.2.3 because of an unfortunate bug in an extension, introduced in 4.3, that no subsequent release has fixed. I helped them to get 4.2.3 running on Solaris 10. The bug was the kind of thing that you could ignore if you didn't rely on actually getting error handling with stored procedures. - Matt -- Matt Ingenthron - Web Infrastructure Solutions Architect Sun Microsystems, Inc. - Global Systems Practice http://blogs.sun.com/mingenthron/ email: matt.ingenthron at sun.com Phone: 310-242-6439 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/webstack-discuss/attachments/20071217/7e6d968d/attachment.html>
