Re: PostgreSQL perl / libpq.so.2 problem - again :( - Mailing list pgsql-general

On Friday 06 July 2001 09:04, wsheldah@lexmark.com wrote:
> This might sound like a flame, but it isn't meant to be.  Uninstall the rpm
> packages that are giving you trouble and reinstall them from source.  For
> me, rpm's are just grief, especially for apps that I'm going to do a lot of
> configuration anyway.

For a machine that has only RPM-installed packages, the RPM's can be more
convenient.

> compile postgresql and apache from source, both to get the most recent
> updates immediately and so they could be optimized for that machine.

As the PostgreSQL release cycle is rather slower than much software, this
isn't really an issue for PostgreSQL.  Patience is still a virtue.

> OTOH, if you can get the rpm's to work, by all means more power to you.

RPM offers more to users than just convenience.  But, if you're not
convinced, I'm not going to argue with you.

In my case, I used the RPM's before I started maintaining the RPM's because I
don't install development tools on production servers -- and at the time
Ididn't have a development server to build on.  I now have enough boxen to do
the development with -- but I still prefer the RPM way of doing things, as it
results in a more consistent system.  And I take great pains toleave my
development machines in 'out-of-the-box' condition (except for security
updates) so that the RPM's I build are usable by the most people.

Otherwise, you will have to rebuild the RPMset from the source RPM for your
custom setup.

But, if you start installing core OS packages from source on an RPM box, you
will likely need to install all dependent packages from source as well, as
the RPM database won't have the correct dependency information.

In the example that started this thread, had Perl 5.6 been installed as RPM,
the postgresql-perl RPM installation should have barfed, as it depends upon
the perl version registered with the RPM database to equal 5.00503 -- not
greater and not less.  But  perl 5.6 was installed from source -- and the RPM
database dependencies we're updated -- which could cause more problems than
for just the postgresql-perl RPM, as any other RPMs that depend upon
perl=5.00503 will install silently to the older perl directory, which will be
incorrect.

On a related note, I no longer have RedHat 6.2 or 7.0 boxen -- Red Hat 7.1 is
so much more stable (and so much faster!) that I have migrated all but my
production server to RH 7.1 --and the production server will get the upgrade
next.  If anyone wants to donate a old hard drive or two to see older or
other distributions supported, I won't argue :-).  The installation of Red
Hat necessary to build the RPMset varies, but is almost always greater than
1GB -- a 2 or 3 GB hard drive is enough to install a development set on --
and I will continue support for those distributions as long as the hard drive
lives.....

So, unless things change, future PostgreSQL binary RPMsets will be built only
for RHL 7.1 by me -- others are already building Mandrake 7.2 and 8.0 sets.
You can rebuild from the source RPM fairly easily, though, as long as you
have at least RPM version 3.0.5.  Instructions are in the README.rpm-dist.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11