Eric Boutilier writes: > >Actually, I was proposing that as a bit of hyperbole. I can't imagine > >someone taking it seriously because I believe that in that direction > >lay both architectural and support madness. > > > > > > Fink and Debian don't suffer from architectural and support madness > though...
And we know that because ... why? Seriously, this is near the root of one of the reasons that I abandoned running Debian on my home system, despite the fact that I otherwise liked it. The tortured mess of X needing Y.1 and Z needing Y.2 and me wanting both X and Z was just too much to bear. And, yes, that's even with the indirection mechanism. That package indirection feature doesn't alter the fact that there are subtle differences between each underlying choice. (If there weren't subtle differences, then why would you ever bother choosing one over the other?) I really don't want a "choice" of OpenSSL versions to run any more than I want a "choice" of JVMs. Really, I don't. I just want _one_ that works. To me, having choices like these are actually more constraining than they are liberating. It means that I'm stuck with accepting the fact that different components necessarily result in different (and potentially incompatible) dependencies. > Yeah, the support ramifications is what I fear most. Although Darren M. > has a good point about the pkg tools helping a lot here. They can warn that the user has walked off the edge of what's supportable, but that doesn't erase the underlying problems. What do we say if there's a conflict between what a user deems is necessary for his environment and what we're actually technically capable of supporting? Today, we don't tell customers that they're free to overwrite /lib/libc.so.1 with glibc. Could we be telling them to do the moral equivalent of that in the future? -- James Carlson, KISS Network <[EMAIL PROTECTED]> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
