Re: Yum upgrade of PostgreSQL 8.4 from to rc1 rendered data unusable - Mailing list pgsql-admin
From | Jakov Sosic |
---|---|
Subject | Re: Yum upgrade of PostgreSQL 8.4 from to rc1 rendered data unusable |
Date | |
Msg-id | 20090617013301.3918122b@nb-jsosic Whole thread Raw |
In response to | Re: Yum upgrade of PostgreSQL 8.4 from to rc1 rendered data unusable (Jakov Sosic <jakov.sosic@srce.hr>) |
Responses |
Re: Yum upgrade of PostgreSQL 8.4 from to rc1 rendered
dataunusable
|
List | pgsql-admin |
On Tue, 16 Jun 2009 23:10:40 +0200 Jakov Sosic <jakov.sosic@srce.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/ |
pgsql-admin by date: