Better handling for mixed stable/testing/unstable systems
Hello.
After working with mixed stable/testing/unstable systems for several years,
it seems for me that I know what apt-get needs to support more or less
painless administration of such systems.
1. Currently, it seems that apt's problem-solver consideres exactly one
candidate for each package. On a mixed system, too often the following
happens:
- package A is installed from one branch (e.g. unstable),
- package B is installed from another branch (e.g. testing),
- A is being upgraded,
- newer A versioned-depends on B, and version of B in testing can't satisfy
this dependency.
Currently this causes apt to report an error. So manual "B/unstable" is
needed in the command line. It's not a problem (just somewhat annoying) if
the dependency chain is one-package-long, but when playing with large
packages like KDE it takes too long time to manually find ann individual
packages that need to be "switched to other branch".
Using "-t unstable" (or other way to change branch priorities) is not
convenient, because this will "switch to unstable" also packages for which
such switch is not required. This breaks the "upgrade only if what is
needed to upgrade" policy that I try to follow.
A good solution will be if apt (when a command-line switch is given), if
failes to find an upgrade path, will try different versions of packages.
Seems that dependency information may give hints on which packages to try
non-default versions, so complete enumeration of possibilities will not be
needed.
2. When doing massive operation (dist-upgrade), sometimes apt's solution is
not perfect. It will be good if apt will accept some hints from the command
line (e.g. which pakcages to add, and which to remove).
3. When there are several binary packages built from the same source
package, and one of binary packages is being upgraded, if will be good if
apt (with some additional command-line switch) also upgrades the other
installed binary packages from the same source package. This will help to
avoid unwanted situations like documentation (or support binaries) for a
version of library that differs from installed one.
Such cases can't be handled by dependences: documentation should not depend
on the library because one cat want to install it without installing the
loibrary; documentation should not conflict with other versions of the
library because this will beat people on slow links who prefer to accept a
mismatch.
I am thinking about trying to implement the above.
Is there any documentation on apt internals available?
Reply to: