Re: Yum upgrade of PostgreSQL 8.4 from to rc1 rendered data unusable

From: Jakov Sosic <jakov(dot)sosic(at)srce(dot)hr>
To: pgsql-admin(at)postgresql(dot)org
Subject: Re: Yum upgrade of PostgreSQL 8.4 from to rc1 rendered data unusable
Date: 2009-06-16 23:33:01
Message-ID: 20090617013301.3918122b@nb-jsosic
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

On Tue, 16 Jun 2009 23:10:40 +0200
Jakov Sosic <jakov(dot)sosic(at)srce(dot)hr> wrote:

> This is not a rpm/yum/etc's fault. It's your fault...
>
> Also, "yum update" *quietly upgraded* is nonsense. Either you run yum
> update -y, or you choose yes after yum offered packages.
>
> So it's your and your fault only... Please don't spread FUD because
> rpm/yum work really good.

I was maybe a bit harsh in this mail, so I apologize if someone got
insulted.

I will explain the importance of package managers, and maintaining
system via packages versus via source tarballs.

I can see in many of Windows users this habit of searching for
software on google, downloading tarballs, extracting, and running in
some trouble with either configure failing because of missing header or
make failing. People don't understand at first hand that Unices - and
Linux for example is more closer to being Unix than being anything else
- are maintained differently.

Great thing about package managers is that they resolve all your
dependencies, that they provide working binaries, that they install
much faster, that they are searched for in consistent way, etc etc.
Also, user can focus on actually using the software and not searching
for it, compiling it, and loosing much much time on getting it to
work...
Also, software in packages often has some patches that are not included
in "vanilla" tarballs, patches that enhance functionality or stability
of the product. Or just help software to blend in distro enviroment
better.

Now, for example, if you have software A that depends on software B,
and B is from RPM package. User downloads A from web, compiles it, and
installs it. Few months later, there is an upgrade for B, and user
"silently" ;) updates package B. Software A could stop working, because
libs from B are different than the one A is linked to. And believe me -
it's a mess to find the reason A stopped working, especially if you
restart service A few months after B was upgraded... It's a real hell.

Another point, if you install software from source, you're on your own
with security issues (CVE). You should follow bulletins and feeds to
inform you, and on every CVE you should react by recompiling the new
version of A - instead of just leaving that to the distributor. And
compilation on production server rises load, takes precious resources
like RAM, thrashes I/O...
Also, I do not need to mention that compiler on production system is
potential security issue. Minimalism is *the law* for good servers.

And what about binary bundles? Again similar problems. Package managers
offer you possibility to uniquely match every file on your system to
some package. That way you can have cleaner system.

I maintain dozen of Solaris and RedHat servers, and I find Solaris
much superior in every way over RedHat except in one - number of
avaliable packages. And that one thing is driving me crazy because I
have to lose almost 50% of my time on configuring, compiling,
writing manifests and methods for SMF, integrating it into Solaris
enviroment and finally packaging everything up. And one thing I forgot
to mention - I also lose time on looking for CVE's for the software I
packaged.

So I hope that this post will encourage people to use their yum/rpm
more and source/bundles less. Because that is the Unix way.

Once again, I apologize on my harsh tone in first mail, I guess it was
counterproductive, but I hope that people will benefit from this post
that only tipped the iceberg of the whole package manager issue.

Live long and prosper \V/

--
| Jakov Sosic | ICQ: 28410271 | PGP: 0x965CAE2D |
=================================================================
| start fighting cancer -> http://www.worldcommunitygrid.org/ |

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Kevin Grittner 2009-06-17 13:58:11 Re: Yum upgrade of PostgreSQL 8.4 from to rc1 rendered dataunusable
Previous Message Jakov Sosic 2009-06-16 21:10:40 Re: Yum upgrade of PostgreSQL 8.4 from to rc1 rendered data unusable