This is a collection of miscellaneous lesser known and undocumented tricks, features, questions and answers about APT-RPM.
Q: Is it possible to install a specific version of a given package without
first mucking in /etc/apt/preferences?
A: Use "apt-get install package=version", for example
Alternatively you can specify distribution where to fetch the package from, provided that the repository is set up to support this (release* files contain real information, not just "Unknown") and the repository is in your sources.list(.d):
# apt-get install openssl/unstable or # apt-get -t testing install
Q: A package I installed pulled tons of new libraries along with it. Now I
I want to remove the package but how do I get rid of the extra libraries
as well?
A: Use apt-get -D remove package" to remove package and all of it's
dependencies which no other package requires.
Q: Can I install and remove packages simultaneusly?
A: Yes, you can. In both "install" and "remove" operations you can add
+ or - at the end of package name to indicate whether it should be
installed or removed. For example this will remove "telnet" package
(assuming it's installed of course) and install "telnet-server" in a
a single operation:
In the above, the + after telnet-server isn't really required but it doesn't hurt anything either...
Ever wanted to modify /etc/apt/apt.conf from a script and got wet feet because of non-trivial parsing from, say, shell script? Well, you don't have to modify it, apt can read arbitrary amount of configuration "parts" from /etc/apt/apt.conf.d directory. For example to add package "foobar" to RPM::AllowDuplicated you can just do
# echo "RPM::Allow-Duplicated::="foobar" < /etc/apt/apt.conf.d/foobar.conf
..and never worry about getting those regexp's right on someone's arbitrary
apt.conf. Similarly apt looks into vendors.list.d and sources.list.d
directories for additional vendor GPG fingerprints and repository entries
(sources.list.d is new as of 0.5.5cnc3).
Note that Synaptic only supports sources.list.d since 0.37'ish.
This is mostly obsolete information as of 0.5.15cnc6, practically all options cause automatic cache rebuild nowadays. Sometimes it seems that no matter what you set some value to, apt behavior doesn't change. In such cases it's usually case of a parameter which is only considered when apt is generating it's cache file. Here's a list of such options known to me, which means it's not complete...
Other non-option things only considered at cache-build time:
So how do you reset the cache, apt-cache knows of no such option? This will nuke the cache and rebuild it: # rm -f /var/cache/apt/*.bin # apt-get update"
There are several options that can be used for debugging apt behavior. Of these -o Debug::pkgProblemResolver=1 with install/upgrade/dist-upgrade operations is probably the most useful when trying to find out why an upgrade isn't going as it should. The full list of available debug options can be found in the configuration option index.
How come pinning doesn't work like the manpage says?
For many features of APT pinning to work the repository needs to support it. That means you need to fiddle with the base/release* files manually and fill some useful content in there. What's useful content? Well, that depends... Read the apt_preferences man page, compare to the definitions below and figure out meaningful values for your purposes!
Keep in mind this is really just a braindump of what I think these things are about, could be wrong here and there as I didn't invent apt pinning... Oh and please correct me if I'm wrong!
Note the frequent use of arbitrary: you're free to use this stuff as you please more-or-less, the intent here is to allow "filtering" (well, pinning) on number of different needs, not just by versions or repositories.
Last updated 01.01.2023