Hello Michael,
For some packages such a list of explicit requirements can get
pretty long and would require an extra maintenance effort. For
instance, not only when depending packages are renamed or when the
dependencies of a package change (user would install redundant
stuff).
Firstly, this splitting up or renaming of packages is a seldom
occassion. That already significantly reduces the maintainance cost.
There are two cases in which Requires would change:
1) The package gets split up and the depended on file is moved to the
new package. (If it is left in the old part nothing changes.) A
Requires for the new package needs to be added, but this is obvious and
the maintainer can solve this by once querying the rpmdb. After adding
the new Requires the maintainer should delete the redundant package
requirement. This should be obvious since the maintainer was prompted
by the fact that (s)he needed to add a new Requires. But even if missed
this can be repaired as soon as spotted. Maybe a redundant package gets
installed, but in most cases it is probably required anyway.
2) The package is renamed. A Requires for the new name needs to be
added, and since the old name no longer exists the old name needs to be
removed. The fact that both steps need to be performed can't be missed
(unsatisfied and unsatisfiable Requires respectively).
But also when a particular version of a library is found
only in a particular package revision. We should rely on tools which
solve the dependencies for us and which find out what package to install
to get libfoo.so.3.
One can use version requirements for package names.
Bye,
Leonard.
--
How clean is a war when you shoot around nukelar waste?
Stop the use of depleted uranium ammo!
End all weapons of mass destruction.