Re: PostgreSQL perl / libpq.so.2 problem - again :(

Hi all,

Are you familiar with Symantec Ghost?

The way I work I keep fresh installed versions of Mandrake 8.0, Win NT
(with SP6a), Solaris 8.0 INTEL, etc, as compressed image files.  When it
comes time to build software on a "freshly installed" machine it takes
just under 10 minutes to restore the appropriate image to a hard drive
with Ghost.

Works well for me.  What do you guys think, good approach?

:-)

Regards and best wishes,

Justin Clift

Lamar Owen wrote:
>
> 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
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly