Being able to share and depend on other people's libraries is great for the developers as long as they're not tied to providing support for when users can't compile or run their software.
Being able to share and depend on other people's libraries is great for the developers as long as they're not tied to providing support for when users can't compile or run their software.
The problem is that about 80% of packages in distributions could be compiled against older versions of dependencies, but never do. Be default, distributions mark in the packages the dependency of their currently installed libraries, ignoring the fact that the software could have been compiled against an older version of the library too.
There's no mechanism for identifying such minimum possible dependencies.
Of course, it may be that the maintainer always specifies the latest version,
But it takes over with dependencies of newer versions than necessary.
Er, yes there is, and there has been for at least the last 12 years, and probably more.
Requires: python >= 2.6.1
Requires: python
The automatic mechanism in place is to run ldd, identify the list of libraries used by the executables distributed, and mark those libraries as dependencies. Since the package is build on your newer, Debian 5 package, it requires (automatically) the newer libfoo (like python-2.7), while it would have worked just fine with the older libfoo (python-2.5).
>> Yes there is
> What you mention is a manual mechanism
I agree, they should ditch the automatic ldd method. I justy wanted to correct the inaccuracy of saying there wasn't a way to specify min versions.
Is this true? It seems like this would be one of the most obvious essential features of any package management system.