James Carlson wrote:
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.
Fair enough. But I think I should clarify my statement "Debian's and
Fink's success seems to contradict the assertions" etc...
Debian, Ubuntu, Mepis, Knoppix, and DSL being Debian based, means that
the Debian architecture is massively ubiquitous and (I think) growing at
a rapid pace.
Of course, despite their popularity, these distros' common way of
handling the dependency and the path problem might truly be a very bad
thing that should not be duplicated as you assert. But weighing the
magnitude of their aggregate popularity vs. your argument, I for one
remain unconvinced.
Eric
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?
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
