On Tue, Mar 27, 2007 at 05:22:59PM -1000, Joseph Kowalski wrote: > David.Comay at sun.com wrote: > >What's the reason, then, to ship /usr/bin/java or /usr/bin/perl? I > >guess I don't quite see the difference. > There are lots of reasons to ship these. > > Maybe we are talking about different links. The one I'm referring to > was only > in the discussion, and not the spec. > > If the link you are talking about is: > /usr/bin/foo -> /usr/foostuff/v1.2.3.4/bin/foo > there isn't a lot to discuss. > > If its: > /usr/bin/foo -> /etc/foo-redirection/foo > /etc/foo-redirection -> /usr/foostuff/v1.2.3.4/bin > and foo-redirection is editable, then there is a lot to discuss.
I agree. Customers should have no control over the "default" version of X in _Solaris_ if X is bundled in _Solaris_. Other OpenSolaris distros can do as they please. > Note that the above is the Java model and it was viewed as an exception, > rather > than a precedent. (Aside: I can't tell you how much I wish the redirection > link was in /etc rather than /usr - mucho zone pain.) But that model fits other things that need it for the same reasons as Java. Or is there something really special to Java and, possibly, Perl that there isn't to Python, Ruby, Apache, PHP, etc...? The common thread isn't that they are languages -- they aren't all -- nor that they are OSS -- they weren't all always -- but that for better or for worse they are or we can expect they to ultimately be versioned, and that minor backwards incompatibilities between versions will necessitate temporary, or even permanent bloat, abhorrent though that might be. Nor does not including multiple versions of such things obviate DLL hell -- customers will still have that problem. We might claim that DLL hell isn't our fault if their multiple versions of stuff won't come from Sun, but that's not useful to the customer: DLL hell does not arise from OS vendors' decisions to bundle multiple version of anything, but from the existence of multiple, somewhat backwards incompatible versions of those things in the first place (if we don't ship them then customers will install them from elsewhere). So if DLL hell were a motivating factor (it's been mentioned) for an ARC opinion here then perhaps we could work to setup Best Practice documents that developers of versioned software can follow to minimize DLL hell. The example I gave for C (linking libraries as local groups and not keeping any global state in libraries that might conflict if multiple versions of them are loaded in one process) might be generalizable for other languages, and may lead to advice to developers of run-time environments for various programming languages. > Maybe an easier task (rather than a general best practice) would be to > articulate why this is like Perl. I still haven't found time to review the > Perl decision, but I suspect you may find the reason we did this for > Perl was also an exception (one time event) and doesn't apply here. > Then again, I'm old enough to have lost many, many neurons, so > maybe not. Without looking I find it _hard_ to believe that there is anything particularly special in the case of Perl that does not apply to AMP. I would not count Sun-internal dependencies on multiple versions of Perl as "something special" -- that would seem unfair to customers who develop similar dependencies over time. Nico --
