On 15/08/14 20:21, Thomas Eriksson wrote:
>
> On 08/15/2014 07:45 AM, Toralf Lund wrote:
>> Hi,
>>
>> Does anyone know if there is a clean way to "downgrade" to the old rpm
>> package when it was previously replaced by another that obsolete it?
>>
>> I mean, say that I have installed some rpm "A-1.0-1.x86_64.rpm", and
>> along comes "B-1.0-1.x86_64.rpm", whose spec has
>>
>> Obsoletes: A
>>
>> Now, if I do "rpm -U B-1.0-1.x86_64.rpm" or "yum install
>> B-1.0-1.x86_64.rpm" or (if B is available through an enabled repository)
>> "yum update", what happens is that "A" gets removed and "B" is installed
>> in its place. Then I decide I want to switch back to "A". So what do I
>> do? I know that one answer is
>>
>> rpm -e B
>> rpm -U A-1.0-1.x86_64.rpm
>>
>> - but what if A and B provide facilities required by other installed
>> packages? I'll then have to pass "--nodeps" when removing B, but that's
>> something that I really want to avoid as it means loosing control over
>> whether all dependencies are satisfied. So is there an alternative?
>>
>> "rpm -U A-1.0-1.x86_64.rpm" alone seems to fail with file conflicts,
>> assuming "B" replaces some of "A"'s files. In a real scenario I tried,
>> there was no mention of the fact that something that was essentially a
>> newer version of the same package, was already installed.
>>
>> "yum upgrade A" (when the package is available on a repository) fails in
>> a similar manner.
>>
>> "yum localinstall A-1.0-1.x86_64.rpm" is a bit smarter - it exists with
>> a message like "Cannot install package A. It is obsoleted by installed
>> package B".
>>
>> "yum downgrade A" (via repository) says something like "No Match for
>> available package: A-1.0-1.x86_64.rpm".
>>
>> "yum localdowngrade A-1.0-1.x86_64.rpm" would seem to have the highest
>> probability of success based on the above, except that there is no such
>> command :-/
>>
>> Any other ideas?
>>
>> - Toralf
>>
> You can try using 'yum shell'
>
> # yum shell
>> remove B
>> install A
>> run
Ah, yes. I sort of forgot that there was such an option.
Maybe this is the best solution. I mean, I'd really like to have
something somewhat "more automatic", but this way at least you don't
loose control over the dependencies.
Thanks,
- Toralf
>
> Thomas
> _______________________________________________
> CentOS mailing list
> CentOS@xxxxxxxxxx
> http://lists.centos.org/mailman/listinfo/centos
This e-mail, including any attachments and response string, may contain proprietary information which is confidential and may be legally privileged. It is for the intended recipient only. If you are not the intended recipient or transmission error has misdirected this e-mail, please notify the author by return e-mail and delete this message and any attachment immediately. If you are not the intended recipient you must not use, disclose, distribute, forward, copy, print or rely on this e-mail in any way except as permitted by the author.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
