I'm not sure if this should be aimed at rpm or yum, anyway:
I have a suggestion that during installation, rpm should store a refcount for
every package that is merely installed due to dependency. For example, when you
install Abiword, many dependencies are needed. But when you later uninstall
AbiWord, most of those dependencies will remain installed - presumably to no
use, only wasting disk space.
With the refcount, rpm could detect that the dependencies are no longer needed.
And so it would remove them too.
Of course this would only happen if the refcount decreases to zero, so if there
are other applications requiring a certain package, it would not be removed.
yum install yum-utils
List leaf nodes in the local RPM database. Leaf nodes are RPMs
that are not relied upon by any other RPM.
You can use the package-cleanup --leaves option to automate removal.
Thanks, but that program doesn't seem smart enough. It simply lists all packages
that no other package depend on. For example, if I have removed abiword and then
also want its dependencies (as listed below) to be removed, I would need to use
the --all switch to have any of them listed.
And that is too dangerous - it would imply removing also vital applications like
nautilus, evolution and pirut.
So it doesn't do what I requested, i.e. when you install a package, store a
reference for every package that was suggested by yum as a dependency to that
primary package. Thus, if you just run `yum install gtkmathview` there would be
no refcount added to gtkmathview. But if you run `yum install abiword`,
gtkmathview is required as a dependency. Then yum should store a refcount on
gtkmathview linked to abiword. Running `yum remove abiword` later, you could be
asked if to remove `gtkmathview` at the same time (if the refcount on
gtkmathview decreases to zero).
That method would be the most accurate way to decide whether a package is really
needed or not. After you've removed abiword, neither of evolution or gtkmathview
is a dependency. But there is a significant difference between those two
packages, despite that they both appear in the list of `package-cleanup --leaves
abiword x86_64 1:2.4.6-1.fc6 extras 6.3 M
Installing for dependencies:
enchant x86_64 1:1.3.0-1.fc6 extras 126 k
goffice x86_64 0.2.1-2.fc6 extras 1.3 M
gtkmathview x86_64 0.7.6-5.fc6 extras 872 k
link-grammar x86_64 4.2.2-2.fc6 extras 355 k
mathml-fonts noarch 1.0-21.fc6 extras 190 k
ots x86_64 0.4.2-10.fc6 extras 52 k
What I mean is, there should be like a transaction control. So that after you
uninstall a package, the set of installed packages should look exactly as it did
before the install.
All installed and removed (if %_repackage_all_erasues 1) packages contain a unique transaction id.
Installed transaction id's are indexed, and the installed packages added by a transaction
can be queried by id using --tid 0x12345678.
Transactions can be removed by using --rollback.
Packages installed by rpm-4.4.4 and later also carry the name of any packages removed
while installing as a "back link":
$ rpm -q --blink zlib
Your scheme of adding a link to parent to dependent package will not work as described because
dependencies are many-to-many, not one-to-one. In other wods, not only abiword may require
gtkmathview, and abiword may require previously installed packages that were installed for
User firstname.lastname@example.org's account has been closed
Reassigning to owner after bugzilla made a mess, sorry about the noise...
Afaik this bug is still present in Fedora 7 and beyond.
*** Bug 221151 has been marked as a duplicate of this bug. ***
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'.
Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.
Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:
The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 7 changed to end-of-life (EOL) status on June 13, 2008.
Fedora 7 is no longer maintained, which means that it will not
receive any further security or bug fix updates. As a result we
are closing this bug.
If you can reproduce this bug against a currently maintained version
of Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.