Re: Basic yum question- latest version isn't latest version.
- From: tblanchard001@xxxxxxxxx
- Date: Fri, 13 Jul 2007 14:35:44 -0700
On Jul 13, 4:32 pm, dterr...@xxxxxxxxxxx wrote:
On Jul 13, 9:27 am, tblanchard...@xxxxxxxxx wrote:
On Jul 12, 7:51 pm, dterr...@xxxxxxxxxxx wrote:
On Jul 12, 3:20 pm, tblanchard...@xxxxxxxxx wrote:
On Jul 11, 9:59 pm, dterr...@xxxxxxxxxxx wrote:
On Jul 11, 4:15 pm, tblanchard...@xxxxxxxxx wrote:
On Jul 11, 3:54 pm, dterr...@xxxxxxxxxxx wrote:
If I want to install the latest stable version of something, yum
doesn't always have it. For example, right now yum has postgres 8.1.9
but the latest stable on postgres.org is 8.2.4.
If I install 8.2.4 from postgres.org that will mess up yum right? Or
be outside of yum...
This is my basic problem with these intsaller things, yum, apt,
whatever...
try reading: man yum
Look at the localupdate option to install a local rpm file, that way
yum database gets updated.
You could run: rpm -Uvh postgreswhatever.rpm then yum update
Thanks. But I get:
# yum localupdate ./postgresql-8.2.4-1PGDG.i686.rpm ./postgresql-
server-8.2.4-1PGDG.i686.rpm . /postgresql-libs-8.2.4-1PGDG.i686.rpm
Loading "installonlyn" plugin
Setting up Local Package Process
Examining ./postgresql-8.2.4-1PGDG.i686.rpm: postgresql -
8.2.4-1PGDG.i686
Examining ./postgresql-server-8.2.4-1PGDG.i686.rpm: postgresql-server
- 8.2.4-1PGDG.i686
Examining ./postgresql-libs-8.2.4-1PGDG.i686.rpm: postgresql-libs -
8.2.4-1PGDG.i686
Marking ./postgresql-8.2.4-1PGDG.i686.rpm as an update to postgresql -
8.1.9-1.el5.i386
Marking ./postgresql-server-8.2.4-1PGDG.i686.rpm as an update to
postgresql-server - 8.1.9-1.el5.i386
Marking ./postgresql-libs-8.2.4-1PGDG.i686.rpm as an update to
postgresql-libs - 8.1.4-1.1.i386
Resolving Dependencies
--> Populating transaction set with selected packages. Please wait.
---> Package postgresql-libs.i686 0:8.2.4-1PGDG set to be updated
---> Package postgresql.i686 0:8.2.4-1PGDG set to be updated
---> Package postgresql-server.i686 0:8.2.4-1PGDG set to be updated
--> Running transaction check
Setting up repositories
Reading repository metadata in from local files
--> Processing Dependency: libpq.so.4 for package: apr-util
--> Processing Dependency: libpq.so.4 for package: dovecot
--> Restarting Dependency Resolution with new changes.
--> Populating transaction set with selected packages. Please wait.
---> Package postgresql-libs.i386 0:8.1.9-1.el5 set to be updated
--> Running transaction check
--> Processing Dependency: libpq.so.4 for package: apr-util
--> Processing Dependency: libpq.so.4 for package: dovecot
--> Restarting Dependency Resolution with new changes.
--> Populating transaction set with selected packages. Please wait.
---> Package postgresql-libs.i386 0:8.1.9-1.el5 set to be updated
--> Running transaction check
Error: Unable to satisfy dependencies
Error: Package apr-util needs libpq.so.4, this is not available.
Error: Package dovecot needs libpq.so.4, this is not available.
[root@lanny arrived]#
Is this going to turn into a neverending downward spiral of
dependencies?
I hate shared libs.- Hide quoted text -
- Show quoted text -
Yes it will be one of those. You can try and google a different
repository that carries the latest version online and then add that to
your yum configuration, that's the best way around this situation. It
looks like you only need one library, try googling that library and
adding it to your system. What linux are you running? I've got that
library on fc6 in /usr/lib.
I'm running centos. Here's how I spent my day:
What I did is uninstall postgres, then reinstall it from the local
rpms. The problem is, uninstalling it also uninstalled mod_ssl. And
mod_ssl wouldn't reinstall, saying it needed libpq.so.4.
I can't even remember what ended up solving that- I think what I did
was install the "comat" rm for postgresql, and then mod_ssl installed.
I'll see if I can tap into some other repository- maybe I can use FC
6's reso somehow.
I still don't understand the point of shared libs. Can't each app
just have it's own personal copy of whatever lib it needs? It's not
like disk space is hard to come by these days. If I compile from
command line I can usually achieve that by a ./configure option, point
to a local copy of a .so file or whatever.- Hide quoted text -
- Show quoted text -
The point to shared libs is that you waste a lot of disk space when a
duplicate lib is loaded for each app, it's also one of the reasons you
have yum, apt, etc... they resolve lib issues and add them if
necessary to keep you from going through this. This is just one of
those time you'll have to get it. Do you have Apache installed? It
should contain mod_ssl (if install the apache ssl stuff).
But disk space is so cheap now. How much extra space are duplicate
so's going to really take? an extra 500 meg at max? I could see
that making a difference for like kiosk and cell phone mini-linuxes,
but for mainstream desktop, laptop, and server distributions like
rhat, debian, etc, what's the point?- Hide quoted text -
- Show quoted text -
Hmmmmmm...... Difficult to answer, I see where you're coming from with
the space issue, advocates of shared libs would argue simplicity,
security, management, and only having to have the library once, ease
of development (because I don't have to package every library I use
with an app I develop). Those opposing shared libs see what you see
and don't like having to track down the one library they need, and
ease of installation.
Let me explain some of the points above.
Simplicity - one library means one source of failure, and one patch
job rather than several. Reading /var/log/messages would be difficult
because it pointed out a failure in lib.so.4, then the question
becomes, "Which one is it?"
Security - I can now hack lib.so.4 in 5 places as opposed to just one.
Ease of development - I want my app to go out fast but if I have to
get every lib I've used, which would be extensive, especially if I use
libs that the kernel itself uses(what would be the point to repacking
those), then my development time and application footprint becomes
much larger. The problem with this is that some people keep their
partitions small and light for a reason, the average user doesn't
build a system based on speed and efficiency, they just want something
that works. To a system builder who has to backup all that data, you
run into potential problems.
Management - If I have 30 apps installed, all of the sudden managing
one server becomes a nightmare, because I've to patch and manage all
those libs n crap.
That's why package managers like yum and apt were created, to ease the
burden of the average joe trying to install an app and not wanting to
get into the internals of a computer.
.
- Follow-Ups:
- Re: Basic yum question- latest version isn't latest version.
- From: Darren Salt
- Re: Basic yum question- latest version isn't latest version.
- From: dterrors
- Re: Basic yum question- latest version isn't latest version.
- References:
- Basic yum question- latest version isn't latest version.
- From: dterrors
- Re: Basic yum question- latest version isn't latest version.
- From: tblanchard001
- Re: Basic yum question- latest version isn't latest version.
- From: dterrors
- Re: Basic yum question- latest version isn't latest version.
- From: tblanchard001
- Re: Basic yum question- latest version isn't latest version.
- From: dterrors
- Re: Basic yum question- latest version isn't latest version.
- From: tblanchard001
- Re: Basic yum question- latest version isn't latest version.
- From: dterrors
- Basic yum question- latest version isn't latest version.
- Prev by Date: Re: rsync transfer preview
- Next by Date: Re: Open source for Kids Education
- Previous by thread: Re: Basic yum question- latest version isn't latest version.
- Next by thread: Re: Basic yum question- latest version isn't latest version.
- Index(es):
Relevant Pages
|