[CentOS] Thanks, good bye, and an observation from a newbie.

[Lamar Owen]

On Monday 17 October 2005 12:49, Les Mikesell wrote:
> On Mon, 2005-10-17 at 09:43, Lamar Owen wrote:
> > ... showing their ignorance to the fact that the initscript can get
> > blown away in an RPM update at whim, but that the config file wasn't ever
> > overwritten...

> Isn't it always up to the whim of the RPM builder what gets blown
> away and what is preserved?  Did you just mean that the config file
> hasn't been changed recently?

No, sorry, I didn't fully explain the postgresql.conf situation.  The 
postgresql.conf is generated from a template during initdb, and is thus 
created along with your database when you initdb.  It is not managed directly 
by the spec's %files list.  Likewise with pg_hba.conf, and any other 
configuration found in $PGDATA (/var/lib/pgsql/data by default).

Thus, unless the packager (at the time me) does something drastic (like, rm 
-f /var/lig/pgsql/data/postgresql.conf ; cp 
some-new-template-for-conf /var/lib/pgsql/data/postgresql.conf or adds 
specific files to %files for the -server subpackage) then the 
$PGDATA/postgresql.conf is pretty much guaranteed safe from overwrite by the 
RPM installation.  There are whims, and then there are stupid tricks.

> > No, Linux isn't for newbies, and ninety percent of the time it's not the
> > distribution's fault.

> What is it that could be explained that couldn't be scripted?

More than you might realize given the constraints of the RPM system.  
Otherwise, very little, but you do have to write and debug the scripts.  And 
the script interpreter, regardless of language, takes things far more 
literally than even the rankest newbie following an explanation.

But to directly answer the question you posed, in the context of the 
PostgreSQL upgrade procedure, there are external limitations that cannot be 
scripted for various reasons, most of which are outside the control of the 
scripts that run during %pre, %post, %preun, and %postun.  The biggest 
problem is that PostgreSQL databases contain a vast amount of 
version-specific metadata, specifically they can contain compiled C functions 
that are version-dependent, and they contain the default type handler 
functions for the whole database (PostgreSQL is extraordinarily customizable 
and extensible, and in fact the default types, operators, and functions are 
implemented just exactly as if they were user customizations, inside the 
database itself.  This is what initdb does, in fact: it loads a default set 
of customizations using a standalone backend and template files).  

The second biggest problem is that these scripts (%pre and kin) cannot tell if 
they are running in an anaconda chroot or from  yum or from a manual rpm 
commandline.  If they are running in an anaconda chroot, 'Danger Will 
Robinson!' : they had better not try to start a backend process, because the 
anaconda chroot with busybox is NOT a suitable place to start a backend (to 
dump the database in preparation for upgrade, something that would have to be 
done in a %pre, and of course you run into serious disk space calculation 
issues).  

Third, RPM scriplets are forbidden (especially inside anaconda, or during a 
yum update or similar) from sending to stdout or gathering data from stdin, 
preventing the scriptlet from asking questions and receiving answers.  And 
the user may never see the output your carefully thought out initscript wrote 
to stdout.

I know what the short-term solution is, but have not had the time or the need 
to implement it.  And that is the capability of having multiple versions of 
the backend available at any given time.  Debian's maintainers are working on 
a system along those lines, but they have run into snags too.

It is far easier to explain "dump, upgrade, initdb, restore" than to write a 
script to do some really hairy data manipulation that can:
1.)	Understand the binary data format;
2.)	Has knowledge of all possible old versions with binary mappings from old 
version default type handlers and new version handlers, with the appropriate 
OID's necessary for mapping;
3.)	Knows how to take an object code function and translate to the new version 
object code function for all possible versions, keeping the same OID;
4.)	Can do all of the above without overflowing disk, or at least handles disk 
space exhausted in a sane manner;
5.)	Oh, and has no possibility of database corruption.

That's just the overview.

Now, explain to a newbie why they can't just stick the disk in and upgrade; 
you'll likely get a blank stare.  This is, IMO, one reason why Red Hat no 
longer officially supports upgrades, and only allows 'upgradeany' at your own 
risk.

Or to put it very bluntly: being newbie-friendly is hard work for a developer, 
but even harder work for support staff or mailing list participants.  There 
are no easy answers for ease of use.  Although my initial impressions of 
Ubuntu are pretty positive.

Personally, I have nearly a decade of experience with Red Hat-like systems; 
too much intellectual equity to jump ship.  One might say I'm somewhat vested 
in RPM-based setups at this point.
-- 
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC  28772
(828)862-5554
www.pari.edu