Usually, rpm --queryformat can be used to generate all sorts of rpm package listing. You could, for example, use the vendor tag to separate the packages that are tagged with RPM Fusion from the list of all installed packages (rpm -qa):
$ rpm -qa --queryformat "%{Name}:%{Vendor}\n" | grep -F "RPM Fusion"
Unfortunately, there is no 1:1 mapping between rpm’s vendor tag and the install repository. In some cases, the vendor tag is just slightly altered (upper case letters, etc.) or the tag is completely empty.
And there is obviously no rpm tag for repositories, since rpm itself doesn’t know anything about repositories (you can list all available tags by invoking rpm --querytags). But of course, yum does!
To get a list of packages from the RPM Fusion repository, you can use
$ yum list installed | grep -i fusion
Resources:
http://unix.stackexchange.com/questions/22560/list-all-rpm-packages-installed-from-repo-x
http://www.rpm.org/max-rpm/s1-rpm-query-parts.html
Usually, rpmbuild related variables are set in ~/.rpmmacros. To change the current working directory, one could simply alter the default settings:
%_topdir %(echo $HOME)/rpmbuild
This would change rpmbuild’s working directory on a per-user basis.
Sometimes it’s quite convenient to keep the default setting and change the working directory on a per-project basis:
$ rpmbuild --define "_topdir workingdir" -ba project.spec
To use the current directory as working directory, one could invoke rpmbuild as follows:
$ rpmbuild --define "_topdir `pwd`" -ba SPECS/project.spec
Careful: Double quotes are mandatory as well as having a proper subdirectory structure in the new working directory (BUILD, SRPM, RPM, SPECS and SOURCES).
Resources:
http://www.rpm.org/max-rpm/s1-rpm-anywhere-different-build-area.html
http://stackoverflow.com/questions/416983/why-is-topdir-set-to-its-default-value-when-rpmbuild-called-from-tcl
Sometimes, rpm dependencies get rather complex. It’s not always easy for an rpm maintainer to keep track of the runtime requirements of his package and therefore, huge rpm dependency trees develop. And it’s even more difficult so see which packages get pulled by yum, because only a tiny part of those are actually listed as requirements in the spec file. The tree gets huge with recursion!
With rpmdep, there’s a small tool that will help you visualize those dependency trees. It’s part of Fedora’s rpmorphan-package, so you can easily pull it with yum:
# yum install rpmorphan
rpmdep itself is just a perl script, that walks down the rpm tree recursively. It can produce a Graphviz dot-file, which in turn can be used to make rather since pictures. For example,
$ rpmdep -dot firefox.dot firefox
$ dot -Tpng firefox.dot -o firefox.png
produces a complete rpm dependency tree for firefox. An exemplary picture (firefox’s dependencies in Fedora 13):
Click image for full size (1.6MB)
Graphvic can produce quite a few output formats. For an overview about all available commands, have a look at http://www.graphviz.org/doc/info/command.html.
When an upgrade includes changes to a default configuration file, the package will write either a .rpmnew or a .rpmsave file instead of overwriting the configuration file on your system. Which file a package creates is up to the discretion of the package maintainer.
From “Dealing with .rpmnew and .rpmsave files” By Bruce Byfield:
An .rpmnew file contains the new default configuration file and leaves your original configuration file untouched. By contrast, and .rpmsave file is a copy of your original configuration file, which has been replaced by the new default file.
The following script can be helpful to find (and possibly merge) those files with your original configuration
for a in $(find /etc /var -name '*.rpm?*'); do diff -u $a ${a%.rpm?*}; done
You may also want to check on yum-merge-conf, a yum plugin to merge configuration files.
Sometimes, packages you never actually use get installed as dependency by yum (or even during initial installation by anaconda). package-cleanup is a great tool that helps you find packages not required by other packages. It it part of the yum-utils package which can easily be pulled with yum:
# yum install yum-utils
1. Find and review “unused” packages
You can find packages not required by other packages with
# package-cleanup --leaves
These packages could be candidates for removal, but check to see whether you use them directly or if they are used by applications not backed by rpm packages.
2. Find and review “lost” packages
You can find orphaned packages (i.e. packages not in the repositories anymore) with
# package-cleanup --orphans
This will also show packages which have been partially uninstalled but where the “%postun” script failed.
See also package-cleanup manpage
