[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: The looming Python 3(000) monster

On Fri, Dec 5, 2008 at 1:08 PM, Les Mikesell <lesmikesell gmail com> wrote:
> I thought that was a separate problem (in a flurry in the FC2/FC3 era) but
> similar in dealing with RPM swapping incompatible db libs underneath itself.
Hey your the one who brought it up. rpm transactions which abort in
the middle...are a general problem. There is nothing yum or python
specific about it. If an rpm transaction which updates python and all
that depends on that new python stops in the middle before completing
you have a problem. Just as you would have the same problem if the
transaction failed while updating any dependancy chain..including

The answer right now is... don't let the rpm transaction stop in the middle.

>  I recall for a while I defensively did a separate run of yum to just update
> rpm and yum to minimize the chances of failure or mismatches  pulled from
> out-of-sync repos before starting a larger update.  I don't think there have
> been many problems recently, but it will still be tricky to make the
> yum/python switch foolproof - especially if you don't permit multiple
> versions of python to exist at once.

If you can't solve the general problem of fool proofing rpm
transactions..if rpm transactions can fail or be terminated in the
middle..without a way to come back and finish where they left
off...then no there is no way to foolproof an update..even an update
to rpm itself if an important library necessary for rpm operation was
in the transaction.

Do not let rpm transactions fail in the middle. Do not forcibly
terminate them...do not cut power to the system...hold your breath and
walk away from the console.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]