[Unfortunately the WebRTI discussions tend to end up cc'd to the list of recipients getting the WebRTI emails, which leaves out the rest of the community. I'm redirecting this thread to the webstack list as a whole since it is a technical discussion.]
Prashant Srinivasan wrote: > > >I understand the postinstall is doing the version check. But the > >correct way of making sure that /usr/bin/ruby is linked to the latest > >version is to deliver the link that way in the pkgmap itself. This is > >the way /usr/bin/perl is delivered in OpenSolaris rather than having a > >postinstall script do it. > > To change topics to 6641045 - here's what we think are important to Ruby > users on Solaris > > (1) to have Ruby invokable OOB(by placing a link to Ruby in a directory > in $PATH) > (2) to be able to have multiple versions of Ruby installed on the > machine at any given time. > > #1 is important for usability(obviously), and #2 is important > especially across incompatible versions of Ruby. ie., the x.y to x.y+1 > releases. Ruby's popularity is tied to Rails adoption - and Rails > 'certifies' against a particular version of Ruby. In this case, it is > 1.8.6. The latest Ruby version is 1.9. We expect that folks will use > different versions of Ruby for different things on the same machine. > > The postinstall scripts achieve #1 and #2. Now we know that this(ie., > scripts) are not acceptable for Indiana.(I've had many 'love-letters' > sent to me about this already ;-) IMO the key part is that the ruby postinstall script doesn't accomplish any goal because it doesn't get run because IPS doesn't support those scripts. So, it's a moot point to analyze what it might accomplish, since it can't... I know, the old packaging still exists in e.g. SXDE, but since Indiana/IPS-based [preview] distros are already here, it also needs to be considered now. As to 6641045, it appears there isn't an extreme urgency to fix it right now. If you had been trying to meet a date to go into b79 for the next Indiana preview I think it would've made a lot of sense to quickly fix 6641045 by itself (adjust awk paths) and worry about proper solutions later. But since that's not the case anymore, IMO it's better to take time and fix 6632021 (the postinstall scripts) which will, as a side effect, make 6641045 go away. As to analyzing options for 6632021, maybe it'd be useful to produce a small matrix of options & consequences in all relevant scenarios to make the choices more concrete. At least, that's an analysis approach I've found useful in the past. -- Jyri J. Virkki - jyri.virkki at sun.com - Sun Microsystems
