Ticket #806 (closed defect: fixed)

Opened 5 years ago

Last modified 8 months ago

Fix self-obsoletes and self-conflicts behavior


Reported by: pmatilai Assigned to: RpmTickets Priority: major Milestone:
Component: rpm Version: RPM Development Keywords: Cc:


Description (Last modified by pmatilai)

This doesn't seem particularly meaningful behavior (self-obsoleting package):

[root@dhcp102 noarch]# rpm -Uvh self-obsoletes-1.0-1.noarch.rpm 
Preparing...                ########################################### [100%]
   1:self-obsoletes         ########################################### [100%]
[root@dhcp102 noarch]# rpm -Uvh self-obsoletes-1.0-1.noarch.rpm 
error: Failed dependencies:
    self-obsoletes is obsoleted by (installed) self-obsoletes-1.0-1.noarch
[root@dhcp102 noarch]# 

..and neither is this (self-conflict on name or provide):

[root@dhcp102 noarch]# rpm -Uvh self-conflict-1.0-1.noarch.rpm 
error: Failed dependencies:
    self-conflict conflicts with self-conflict-1.0-1.noarch

At least for the self-conflict case, there's even a potentially use-case for a "singleton" type packages: http://lists.rpm.org/pipermail/rpm-maint/2010-April/002719.html

Change History

11/24/10 09:28:55 changed by pmatilai

  • description changed.

11/24/10 15:49:55 changed by FlorianFesti

Self obsoletes could just silently remove the package from the transaction again. Packages added as erases by this package (as updated or obsoleted) should stay in the transaction. That way it would be possible to issue an update that removes a package from the system without installing something else.

While it is possible to obsolete a package from another package for a) the package got renames or b) is now part of another package it is not possible to remove a package that is no longer necessary if there is no other package taking care of that. An example could be a driver/bugfix/workaround for a special hardware. Even if a later kernel fixes the problem the kernel package might not obsolete the package - may be because the distribution doesn't care or know.

04/24/15 09:17:01 changed by FlorianFesti

  • status changed from new to closed.
  • resolution set to fixed.

This should be fixed as multiple improvement where done to both the conflict and the obsolete handling code.