[csw-users] Why support Solaris 8 onwards?

Ben Taylor Ben.Taylor at Sun.COM
Wed Sep 19 21:37:49 CEST 2007


shuttlebox wrote:

>On 9/19/07, Ben Taylor <Ben.Taylor at sun.com> wrote:
>  
>
>>The bloat is the duplication of packages in blastwave that
>>are in Solaris, especially as you move from 8 to 9 to 10 to
>>11 (nevada).
>>    
>>
Wish you hadn't cut off the next part, where I recognize that Blastwave must
duplicate packages because they cannot depend on Sun to deliver bug fixes
to those patches in a timely manner, or new features in any patch..

>But Suns packages are often not the latest even at release and then
>they will normally just get security fixes and no version upgrades
>which bring new features. As you said, Solaris 10 is almost 3 years
>old now and many want to use fresher versions of bash, perl, Gnome or
>whatever.
>  
>
exactly.

I understand this.  However, there is a goodly portion of the world 
(inside and out of Sun)
that complains pretty vehemently about the "bloat".  I suspect it's more 
a marketing problem
for Blastwave, because most folks don't really understand the 
interdependencies with the
modules, or why Blastwave would choose to use a newer version of a 
module over the
one delivered with Solaris.

>It's up to the user/admin to remove Suns packages if the bloat is a
>problem which it might be due to the extremely annoying patch process.
>  
>
And if you're a production server, in the past, removing packages had a 
tendency to
give Sun support a massive case of kittens.  Anyone who has called Sun 
Support knows
the first question out of the mouth of the person from Bangalore 
(typically) is
"Have you patched?".  Only recently were systems "supported" that were 
minimized.

>How would it be better for users if Blastwave didn't offer the
>"bloat", if they roll their own packages or just compile it into /opt
>or /usr/local they will still end up with bloat unless they remove the
>obsolete versions which belong to Sun, not Blastwave? I think the
>question is - who offers the bloat, Sun or Blastwave? To you, it's
>Blastwave since they are installed later but to me it's Sun because
>they bring what I don't want to/can't use.
>  
>
you're splitting hairs about who creates the bloat.  To the rest of the 
world, the duplication
of packages looks like the bloat is created by Blastwave.  Me, I don't 
give a rats @$$.
Blastwave is by far the best in terms of reducing the amount of 
compiling packages I need
and reducing the amount of manual work I have to do.  I size my 
partitions with the knowledge
that I need to assign 2Gb for blastwave software so I don't over run my 
root partition.

>If you rely heavily on Blastwave packages maybe you could install a
>smaller cluster of Solaris to reduce the bloat from the start?
>  
>
I've suggested to Dennis several times that it might be interesting to 
develop a workstaion
installation model for Solaris to make sure there isn't duplication of 
packages.

>>Other instances is just the sheer number of packages required
>>to get one package.  Because there is no master database of
>>dependencies that can be querried remotely, a package has to
>>be unrolled, have it's dependencies checked, and then stop and
>>go get more to resolve dependencies.
>>
>>In a better version of blastwave, the check for dependencies
>>would happen before downloading the first package.  In a standalone
>>environment, the existing model could be used.
>>    
>>
>
>Well, at least Blastwave handles dependencies in an automatic fashion
>instead of just barfing. ;-) I agree though, that it would be nice if
>both pkg-get and the web site optionally could list ALL dependencies
>for a package.
>  
>
Don't get me wrong, having the dependencies in there is definitely 
beneficial.  I remember haivng
to install something from Sun FxxxWxxx and felt like I wanted to chop 
off my toes after having
to do that dance.

A database that managed all the dependencies would probably be 
beneficial to the entire
blastwave development community in terms of managing that sort of thing.




More information about the users mailing list