The reason was simply that in case of a long
dependency chain, you end up with a long list of packages to install
manually. Who really wants that?
In such cases it would probably be easiest to indeed use an update
tool. But many cases are not that complicated. If I wanted to add a
package to an installed system most of the time it would only have one
or two depdencies in which case I could just pop in the cd or take the
needed packages from my update directory. No need to go online and/or
use an update tool.
Now as soon as you start using small helper scripts to traverse the
dependency tree and collect explicit package names, this is becoming
messy. Just observe, that you need physical access to all missing
packages in order to solve dependencies (the complete rpmdb takes less
The script I added was just to show how simple it would be to generate
these requirements. If it were modified to be used as an update tool of
course it should use the rpmdb. But that's a different thing.
You don't want to include the complete dependency chain in every
individual package, do you?
In most cases the dependecy chain is about 3, 4, 5 items long. Since
one builds from the base, on most installed system 2, 3 chains are
So, why not go one step further and do the
real thing? That is, upon package installation, let RPM and package tool
front-ends solve the dependency chain automatically by querying an rpmdb
and possibly network servers?
As argued above, in many cases one wouldn't need to use such a tool. I
am not disputing the usefulness of update tools in certain instances,
but I do not need a cannon to kill a mosquito.
As a side-note, RPM cannot know that program X from package Y is
executed in script A from package B. Hence in some cases, explicitly
listed requirements are likely to stay.
? This argument I don't understand. This is what the requirements are
used for, but it doesn't matter whether files or packages are mentioned
as requirements. ALso not sure if you mean package or file names with
"explicitly listed arguments".
Currently both file and package dependecies are mixed. So it's
definitely not the case that all needed files are always explicitely
mentioned. Nobody has yet explained to me why there are still packages
depending on packages anyway.
For now I stick to mho that also adding package names to the Requires
is good for clarity (educational), helps people solve many of the less
complicated dependency problems without having to rely on update tools,
and is cheap both in package size and maintainance cost.
How clean is a war when you shoot around nukelar waste?
Stop the use of depleted uranium ammo!
End all weapons of mass destruction.