[rescue] PHP for Solaris?

[Skeezics Boondoggle]

On Tue, 21 Oct 2003, Curtis H. Wilbar Jr. wrote:

> Exactly why do people have to do RPMs on sparc ???  What is so wrong
> with Solaris' package format (I've put packages together many times...

I started building with RPM for Solaris in 1998 or so, as part of a major
infrastructure overhaul for a sprawling, neglected, complex network at a
local graduate school.  We debated the pros and cons of using native tools
vs. a common, cross-platform tool for weeks.  Eventually we chose RPM
because (5 years ago) there weren't any better alternatives, and it was
simpler for a team of three guys managing a half dozen Unix variants and
>300 machines to use one common packaging format rather than learn how to 
build packages with the native tools for Solaris, Irix, Ultrix/DEC Unix,
HP-UX, NeXTstep, etc., and SunOS 4 (which was still in production then,
and today) doesn't _have_ a native packaging format.

The main benefit in that situation was that it replaced a hodge-podge of
build systems that were slow and complicated.  The #1 argument against the
Solaris packaging method is that it doesn't capture the build steps - and
for us repeatability was a crucial step.  They used to maintain a README
file and use RCS for most of the important packages - so maintaining local
mods meant you had to spend n hours going through all the bloody diffs and
patching things, and it was a fookin' disaster.  By always building from
pristine sources and capturing *all* the build steps in the spec file, a
small team of sysadmins/developers can make sure that someone doesn't miss
a step or tweak something by hand and forget to document it.

RPM's other benefit was that it was easy to manage upgrades, make queries,
verify checksums, etc.  The Solaris package tools are kinda slow, you have
to admit.  And it simplified things for us conceptually; "If it comes from
the vendor in the native format, we install it in the native format.  If
we build it from scratch, it goes in /usr/local and we use RPM."

(Of course, then there's IPFilter, which breaks all the rules. :-)  So I
build the ipf.pkg with RPM and install it in the shared /usr/local/etc,
then pkgadd it from there on the hosts that need it.  I know!  I know!  
"Special Instructions" are bad! :-)


> it isn't hard).  I just don't get it when someone puts together packages
> in a non native format... now you have two package management systems
> on your system..... errr..... 

Yes, that's a drawback.  But we integrated RPM into a comprehensive
infrastructure management system, using automated/scripted installs
wherever they were available (Jumpstart, Kickstart, etc), RPM to manage a
complete and full-featured /usr/local for all platforms, and Cfengine to
tie it all together.  All of those tools have their quirks and warts;  
cfengine is one of those packages I love to hate, and it's mostly because
I haven't had time (since 1995? :-) to sit down and write something
better.

(Ever notice how there are so many packages where brilliant coders wrote
lovely code to implement a stupid, flawed idea?  And so many packages
where a good idea was mired and lost under a mountain of horrific,
unmaintainable code?  Sigh.  But I digress.)

And I should also mention that I *hate* the "all the world's a Linux box"  
mentality - and having sent in numerous build patches to various places
because some lazyass checks in a Makefile or source code that builds okay
on _their_ hacked-to-hell RedHat 6.2 desktop with gcc 2.8.1 does NOT mean
it builds cleanly anywhere else.  ARGH!  (And I remember when "all the
world's a Sun" and "all the world's a Vax" before that... so the third
time around it's *really* grating, and I've done my share to seriously
piss off Linux people about it plenty. :-)

-- Chris