Sometimes you need to perform a major package layout restructuring. As in, you need to replace a pool of packages with another pool of packages, with totally different provides and package splits. Since you can not do many to many obsoleting, one way to achieve this is a transition metapackage: 1. You create your new pool of packages with their internal dependencies, etc relations as if no past existed (clean new state) 2. You add a special empty package or subpackage that obsoletes all the packages in the old pool, and requires all the packages in the new pool you want installed by default for upgraded systems 3. You hide this special package from new users, and let them select packages normally This is sufficient to garbage-collect the old package pool and get everyone (new installs and upgrades) in the new state. Victory! Unfortunately, you still have your garbage-collecting metapackage installed on upgraded system. It really has no point anymore, but you can not obsolete it with one of your new long-term packages till you're sure every user of the old pool has migrated (or your break your upgrade path). And at the same time, the longer you keep it available the longer you risk one of your fellow packagers decides to add a dep on it because that's easier than trying to understand the awesomeness of your new package pool. It would be great if it was possible to add a flag to this package that basically told rpm "remove this package just after installation, it has served its purpose, do not keep it".
just my thoughts. no.
1. Install yum-post-transaction-actions 2. Install a file in /etc/yum/post-actions/mypkg-auto-remove.action which does: mypkg:install:yum remove -y mypkg ...the above works, and is Seth's fault :)
This bug has been triaged
(In reply to comment #2) > ...the above works, and is Seth's fault :) The above does not really work, since: 1. it replaces a manual rpm -e at the end of the transaction by another manual step before the transaction, so you win nothing 2. if you try a self-contained system with the package itself requiring yum-post-transaction-actions and installing the file, yum does not take it into account in this transaction 3. it's yum-specific; I had RFCed something at the rpm level to be agnostic (ok I could live with this bit if the rest worked but it does not)
FYI: http://rpm5.org/community/rpm-devel/3245.html Thanks for the RFE.
Nicholas, the post-transaction plugin happens AFTER the transaction has ended. It is safely away and doesn't suffer from the removal problems. Also the plugin doesn't run until after the files are laid down. so a package can use it to take action on itself.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
In most cases you can just add the necessary Obsoletes: to one of the new packages. While this might not be as beautiful as a dedicated solution it should be good enough.