This definitely brings up some great questions. - How will we support the continual process of updating these package? - How do we insure compatibility and avoid dependency nightmares? - What issues are we trying to fix?
I agree that we need to avoid the pit falls the Linux distro's fall into by being too bleeding edge. At the same time, we can't push out these components and expect customers to be happy with the same version 6 months or 2 years down the road. They'll just compile their own, which defeats our efforts. Perhaps what's needed is some level of separation between what's considered stable and core to Solaris and what's volatile to change? Does that mean we push a lot of stuff out of /usr and into /opt or /opt/sfw? Does that mean we support multiple versions of components within a common directory structure (think of the versions we maintain of the Java JDK under /usr/jdk) ? Do we pick one version to be a the default *stable* version, but supply newer versions for customers to try? How many versions will we support within a release? These are indeed difficult questions that need to be answered. But the community as a whole has to come to an agreement and stick to it for the sake consistency. --- Eric Boutilier <Eric.Boutilier at Sun.COM> wrote: > On Thu, 22 Mar 2007, Paul Jakma wrote: > > On Thu, 22 Mar 2007, John Plocher wrote: > > > >> In a sense this is the "gentoo" model, applied to the whole > >> consolidation; it is no longer acceptable to /just/ update a > single > >> subcomponent, the whole wad needs to be in sync. > > > > Choice #5: Explicitely list the dependencies in our packages, make > our > > tools figure out what is compatible based on dependencies. I.e. the > > RedHat/Debian RPM/Deb model. > > I can't speak authoritively about reliability of dependency > architectures. > But there are apparenly widely felt, impactful (in customer-land too) > flaws > in the Debian/Ubuntu architecture that (if true), should either a.) > be > carefully scrutinzed before being allowed into Nevada, or b.) Be put > on > trial first via another SX-like mechanism (e.g. officially endorsing > the > Belenix distro and doing it there.) > > Eric > > > > > > I believe that's what our marketing has found that our customers > want. I > > know for a fact that the lack of such has ruled out Solaris for one > > highish-profile web-server deployment.. > > > > IMHO we really need to stop dealing implicitely with dependency > > resolution by dint of big wads... > > > > regards, > > -- > > Paul Jakma, > > Solaris Networking > > http://opensolaris.org/os/project/quagga tel: EMEA x19190 / +353 1 > 819 9190 > > > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc at opensolaris.org > *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Octave J. Orgeron Solaris Systems Engineer http://www.opensolaris.org/os/community/sysadmin/ http://unixconsole.blogspot.com unixconsole at yahoo.com *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* ____________________________________________________________________________________ It's here! Your new message! Get new email alerts with the free Yahoo! Toolbar. http://tools.search.yahoo.com/toolbar/features/mail/
