Hi Everyone, I love the comment about jello and concrete:) I definitely agree this is a challenging issue. But at this point it's probably something that should be moved to a separate discussion so it doesn't stall things for others. We can always sort these issues out over the next couple of builds.
I do like the idea of having meetings to discuss this since it's a huge topic. Hopefully, that's something we can do publicly to get the input of the community. Octave --- Joseph Kowalski <jek3 at sun.com> wrote: > James Carlson wrote: > > Joseph Kowalski writes: > > > >> In any case, I don't see that keeping multiple versions of this > stack on > >> Solaris makes any sense. We could build versions into the paths, > doing > >> the moral equivalent of static linking (as seems to be proposed), > but it > >> seems this would be counter to the assertions just made about path > > >> compatibility being important when importing from the FOSS world. > >> > > > > If we have other system bits being delivered (such as subversion) > that > > depend on out-of-date versions of the stack components, then what > > choice do we have? > > > > We either allow those other system bits to fail in the field, we > > deliver and manage to maintain multiple (accumulating) versions, or > we > > somehow rewrite those other bits to deal with the stack's > volatility. > > > What do you mean by "system bits"? I'm going to assume you mean > something > delivered as part of the Solaris product. > > If this is the case, we do what the distros do and the community > expects > to happen: > we select a set of "system bits" which are mutually consistant or we > tweak those other > bits to create a set of system bits that are mutually consistant. We > > hold steady on > those bits until the commitment level allows us not to. > > I suggested two possible commitment levels: Uncommitted and Volatile. > > Both of > these require us to implement contracts for "system bits" which cross > > consolidation > boundaries. Unless the number of these are very small, Volatile > would > be a nightmare. > It would also make this fairly useless for our customers (IMHO). > Hence, > we need to > make it Uncommitted, and lock down on a version for the duration of a > > Minor release. > Heh! Isn't this what the distros are asserted to do? I doubt they > were > happy about it > either. > > I'd like to point out that we are proposing to do here is pretty darn > > close to what we as > ARC members have objected to in multiple JES proposals. > > Let's assume that we allowed the versioned directories (and no > "latest > link", because > that won't help and only complicates the discussion). Assume we ship > > 1.2.3.4-tuesday > and 1.3.2.4-thursday. What do we do with the CR from a customer that > > requests > 1.2.4.5-wednesday? Do we just ignore it, asserting the versions are > just > for our special > selected set of applications? > > I'm not contending there is a good answer here. Stacks which aren't > asserted to be stable > are a royal pain to support. We know that. The Linux distors know > that. > Even the Linux > consumers know that. > > The Linux consumers deal with this in two ways: > > 1) They go to the community, download latest bits and update the > > version delivered > by their distro. If that works, they are done and happy. > > 2) If that doesn't work, they shove those latest bits somewhere > else on the system and > use this now, APPLICATION PRIVATE copy. > > We simply can't do better than the community will let us. We can't > wave > a magic wand > and turn Jello into concrete. > > I don't want to debate this too long in e-mail. The adding of these > multiple versioned > directories, which require a yet unspecified inclusion/support > policy, > simply pushes > this out of the domain of a fast-track. We will be much more > efficient > discussing this > in a meeting (or several). > > If we pursue the multiple version, I'd like to be pleasantly > surprised > to be presented a > support model which is workable and cost effective. One might be > possible for a > very limited number of versions (PHP4, PHP5). I'd be quite surprised > if > one was > possible for arbitrarily deep versions. > > - jek3 > > _______________________________________________ > 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 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* ____________________________________________________________________________________ Bored stiff? Loosen up... Download and play hundreds of games for free on Yahoo! Games. http://games.yahoo.com/games/front
