[Beowulf] A press release

[Prentice Bisbal]

Tim Cutts wrote:
> 
> On 2 Jul 2008, at 6:06 am, Mark Hahn wrote:
> 
>>>> I was hoping for some discussion of concrete issues.  for instance,
>>>> I have the impression debian uses something other than sysvinit -
>>>> does that work out well?
>>>>
>>> Debian uses standard sysvinit-style scripts in /etc/init.d,
>>> /etc/rc0.d, ...
>>
>> thanks.  I guess I was assuming that mainstream debian was like ubuntu.
> 
> It's sort of the other way around.  Remember that Ubuntu is based off a
> six-monthly snapshot of Debian's testing track, which is why Hardy looks
> a lot more like the upcoming Debian Lenny than it does like Debian Etch.
> 
>> interesting - I wonder why.  the main difference would be that the rpm
>> format encodes dependencies...
> 
> The difficulty is that many ISVs tend to do a fairly terrible job of
> packaging their applications as RPM's or DEB's, for example creating
> init scripts which don't obey the distribution's policies, or making
> willy-nilly modifications to configuration files all over the place,
> even in other packages (which in the Debian world is a *big* no-no,
> that's why many Debian/Ubuntu packages have now moved to the conf.d type
> of configuration directory, so that other packages can drop in little
> independent snippets of configuration)
> 
> I have seen, for example, .deb packages from a Large Company With Which
> We Are All Familiar which essentially attempted to convert your system
> into a Red Hat system by moving all your init scripts around and
> whatnot, so once you'd installed this abomination, you'd totally wrecked
> the ability of many of the main distro packages to be updated ever
> again.  Oh, and of course uninstalling the package didn't put anything
> back the way it had been before.
> 
> Like you, I tend to use tarballs if they are available, and if I want to
> turn them into packages I do it myself, and make sure they are policy
> compliant for the distro.
> 
> So this, while not a statement in favour of either flavour of distro, is
> definitely a warning to be very wary of what packages that have come
> from sources other than the distro itself might do (which of course,
> you'd be wary of anyway for security reasons).
> 
> Tim
> 
> 

Here's another reason to use tarballs: I have /usr/local shared to all
my systems with with NFS. If want to install the lastest version of
firefox, you can just do this:

cd /usr/local

tar zxvf firefox-x.xxx.tar.gz

cd /usr/local/bin

ln -s ../firefox-x.xxx/firefox .

Now all users can use the latest version of firefox (/usr/local/bin is
in their path, and comes before /usr/bin, usr/X11R6/bin, etc.)

With RPM, deb, or whatever, I'd have to use func or ssh and a shell
script w/ a loop to install on all systems (assuming nightly 'yum
update' cron job won't work in this case)

This is incredibly helpful with Python, Perl, R, and other languages
which have additional modules or libraries. Installing additional
modules can be very easy (CPAN module for perl, for example). These
modules aren't included in RPM format (that I know of), and when you
upgrade, perl or python, the RPMs clobber whatever modules you installed
in /usr.

Compiling Perl can be time consuming vs. just installing the RPM, but
once installed, if I run '/usr/local/bin/perl -MCPAN -e shell' as root,
I can install all the perl modules needed just once, and they won't be
clobbered by an RPM update. In the end, this is much more efficient. And
CPAN manages dependencies automatically, too.

We use RT where I work, which requires a few Perl modules. On Friday,
June 13 (Yes, Friday the 13! - it figures. ). I had to stop and restart
our web server that provides RT. The perl packages had recently been
updated. When apache restarted, it couldn't find the necessary perl
modules, and RT wouldn't function. It took me HOURS to track the problem
down to a couple missing perl modules.

--
Prentice