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
