Bug 474704 - RFE: add support for melting packages
RFE: add support for melting packages
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Fedora Packaging Toolset Team
Fedora Extras Quality Assurance
: FutureFeature
Depends On:
Blocks: F11Target
  Show dependency treegraph
Reported: 2008-12-04 16:56 EST by Nicolas Mailhot
Modified: 2015-03-20 05:48 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-03-20 05:48:43 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Nicolas Mailhot 2008-12-04 16:56:43 EST
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".
Comment 1 seth vidal 2008-12-04 17:07:00 EST
just my thoughts.

Comment 2 James Antill 2008-12-04 17:29:34 EST
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 :)
Comment 3 john5342 2008-12-05 20:42:39 EST
This bug has been triaged
Comment 4 Nicolas Mailhot 2008-12-06 06:01:35 EST
(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)
Comment 5 Jeff Johnson 2008-12-07 14:54:19 EST


Thanks for the RFE.
Comment 6 seth vidal 2008-12-07 21:16:14 EST
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.
Comment 7 Fedora Admin XMLRPC Client 2012-04-13 19:13:21 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 8 Fedora Admin XMLRPC Client 2012-04-13 19:14:18 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 9 Florian Festi 2015-03-20 05:48:43 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.