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