From: Matt Giwer on
A question came up over a month ago which has disappeared from my local news
spool. It was with regard to conflicting packages at which point yum would
find an error and exit INSTEAD OF upgrading/updating everything but the
conflict. The words in caps are a hint to yum developers.

I do not recall which newsgroup I read it in so I post to the three I read.

Anyway I was having the same problem and was simply doing piecemeal selective
upgrades of packages that did not involve the conflict. I finally paid
attention to yum messages.

The solution which is hardly clever at all is to use the --exclude option in
yum as follows in a script.

# yum --exclude=pango* --exclude=libexif* --exclude=openldap* -y upgrade
yum --exclude=NetworkManager* --exclude=curl* -y upgrade

Originally my problem was pango. Currently it is NetworkManager and curl.

With this script it has upgraded everything but the problem packages without
further intervention.
From: 1PW "OneNpOeSnPuAtMwhistle att a0l dot on
Matt Giwer wrote:
> A question came up over a month ago which has disappeared from my
> local news spool. It was with regard to conflicting packages at which
> point yum would find an error and exit INSTEAD OF upgrading/updating
> everything but the conflict. The words in caps are a hint to yum
> developers.
>
> I do not recall which newsgroup I read it in so I post to the three
> I read.
>
> Anyway I was having the same problem and was simply doing piecemeal
> selective upgrades of packages that did not involve the conflict. I
> finally paid attention to yum messages.
>
> The solution which is hardly clever at all is to use the --exclude
> option in yum as follows in a script.
>
> # yum --exclude=pango* --exclude=libexif* --exclude=openldap* -y upgrade
> yum --exclude=NetworkManager* --exclude=curl* -y upgrade
>
> Originally my problem was pango. Currently it is NetworkManager and
> curl.
>
> With this script it has upgraded everything but the problem packages
> without further intervention.

* * * Cross posted reply * * *

Hello Matt:

That might have been my post about a problem I called "Dependency
Hell" in the subject, and I encountered this when upgrading my Red
Hat Kitanga from RHEL5.1 to RHEL5.2

One of the posts, in reply to that problem, was to uninstall the
offending RPMs and then yum install. At the time, it seemed too risky
as the file involved no less than 31 dependencies, and therefore
seemed too drastic. But after one week's casual research, (and
agonizing) I arrived at the same answer.

Several times since then, I have encountered similar instances, but on
a smaller dependency scale. I believe that in all cases since then, a
'devel' RPM stood in the way of a base RPM update. So I would simply
do a manual download of all files involved and then do a:

# rpm -e --nodeps rpmtobe.updated /including/ the devel RPM, then:
# rpm -ivh *.* using all the new downloads

I'm acquiring more courage (recklessness) while retaining nearly all
of my stupidity as I practice this. ;-) I followed this procedure
yesterday to accommodate the *freetype* security update from RHN that
failed to deal with its companion 'devel' RPM then present in my
system.

I have just as many reservations with your new found technique as with
mine. I'm afraid I'll leave something undone, or worse. Yum is nice
but more work is obvious here.

My best to you sir.

--
1PW
From: John Hasler on
Matt Giwer wrote:
> A question came up over a month ago which has disappeared from my
> local news spool. It was with regard to conflicting packages at which
> point yum would find an error and exit INSTEAD OF upgrading/updating
> everything but the conflict. The words in caps are a hint to yum
> developers.

It isn't that easy. If the package manager were to proceed in the face of
error conditions it could hose your system. The developers have taken the
cautious approach by exiting and bringing the problem to your attention for
manual intervention.
--
John Hasler
john(a)dhh.gt.org
Dancing Horse Hill
Elmwood, WI USA
From: Matt Giwer on
1PW wrote:
> Matt Giwer wrote:
>> A question came up over a month ago which has disappeared from my
>> local news spool. It was with regard to conflicting packages at which
>> point yum would find an error and exit INSTEAD OF upgrading/updating
>> everything but the conflict. The words in caps are a hint to yum
>> developers.
>>
>> I do not recall which newsgroup I read it in so I post to the
>> three I read.
>>
>> Anyway I was having the same problem and was simply doing
>> piecemeal selective upgrades of packages that did not involve the
>> conflict. I finally paid attention to yum messages.
>>
>> The solution which is hardly clever at all is to use the --exclude
>> option in yum as follows in a script.
>>
>> # yum --exclude=pango* --exclude=libexif* --exclude=openldap* -y upgrade
>> yum --exclude=NetworkManager* --exclude=curl* -y upgrade
>>
>> Originally my problem was pango. Currently it is NetworkManager
>> and curl.
>>
>> With this script it has upgraded everything but the problem
>> packages without further intervention.
>
> * * * Cross posted reply * * *
>
> Hello Matt:
>
> That might have been my post about a problem I called "Dependency
> Hell" in the subject, and I encountered this when upgrading my Red
> Hat Kitanga from RHEL5.1 to RHEL5.2
>
> One of the posts, in reply to that problem, was to uninstall the
> offending RPMs and then yum install. At the time, it seemed too risky
> as the file involved no less than 31 dependencies, and therefore
> seemed too drastic. But after one week's casual research, (and
> agonizing) I arrived at the same answer.
>
> Several times since then, I have encountered similar instances, but on
> a smaller dependency scale. I believe that in all cases since then, a
> 'devel' RPM stood in the way of a base RPM update. So I would simply
> do a manual download of all files involved and then do a:
>
> # rpm -e --nodeps rpmtobe.updated /including/ the devel RPM, then:
> # rpm -ivh *.* using all the new downloads

Thank you. I have not found a way to do other than never upgrade the --excludes

> I'm acquiring more courage (recklessness) while retaining nearly all
> of my stupidity as I practice this. ;-) I followed this procedure
> yesterday to accommodate the *freetype* security update from RHN that
> failed to deal with its companion 'devel' RPM then present in my
> system.

> I have just as many reservations with your new found technique as with
> mine. I'm afraid I'll leave something undone, or worse. Yum is nice
> but more work is obvious here.

So far I have found it errs on the side of extreme caution but maybe it is
just trying to lull me into a false sense of confidence before it strikes.

In preparation for the worst I have all my /home/me/ files on a USB drive
with symlinks in the me directory. They are so damned cheap these days I don't
know why I didn't think of it sooner.

--
You cannot believe torture works without believing in witches.
The problem is most Neocons do believe in witches.
-- The Iron Webmaster, 4013
http://www.haaretz.com What is Israel really like? http://www.jpost.com a7
From: 1PW on
Matt Giwer wrote:
> 1PW wrote:
>> Matt Giwer wrote:

snip...snip

>
> So far I have found it errs on the side of extreme caution but maybe
> it is just trying to lull me into a false sense of confidence before it
> strikes.
>
> In preparation for the worst I have all my /home/me/ files on a USB
> drive with symlinks in the me directory. They are so damned cheap these
> days I don't know why I didn't think of it sooner.
>

Spoken like someone who's been wounded before. Very wise.

Best wishes to you.
--
1PW

@?6A62?FEH9:DE=6o2@=]4@> [r4o7t]
 | 
Pages: 1
Prev: Serial Port
Next: Apache configuration problems