Hi, Am 12.01.2011 14:33, schrieb Angel Popov:
On 11.1.2011 г. 17:35 ч., scott mc wrote:Just a question really: if the package maintainer/developer knows the needed version of library dependencies then can't they just specify a single version (e.g. depend == media-sound/amarok-2.3.2-r1) rather than a range (e.g. depend>= media-sound/amarok-2.3.2-r1)?One of the problems is if say a package was specified to depend on exactly libpng-1.2.43, then 2 weeks later a problem is found with 1.2.43 and 1.2.44 comes out. This newly fixed lib wouldn't do any good for the now installed and locked in app.The's why the library (and not the application) should specify to which older versions of the same library it is binary compatible with. And the application should: - specify (whitelist) library versions it has been successfully tested against. - blacklist library versions that are supposedly binary compatible, but don't work for this application.
All the above sounds good, but:
- be able to see only the most recent version of the library that it is binary compatible with - packagefs should take care of this.
The devil is in the detail here. Usually, applications link against a library name that implies a specific ABI version. If you have two applications installed which link against a specific ABI version, but one of them blacklists a particular version with the same ABI, but the other does not, then what should happen? What library the application is linked against is handled by the runtime loader, which for example sees a link of the library named after the correct ABI version. If we wanted to support the feature you listed, either the runtime loader would have to look at package information (slower start up), the package manager/resolver would have to make sure only the oldest library version compatible with all installed packages is installed regardless of ABI info encoded in the library name (potentially prevents security fixes), or the package manager would have to move installed locations of libraries around dynamically, so the visibility works like you describe. I find that system pretty complicated and I have doubts that it would work in practice. What's more is that it does not prevent broken installations, since there is the moment when the installation is broken before someone blacklists a specific lib version for a specific app (exactly because someone experiences the brokeness). What I find a better approach to this problem is that a) The actual binary compatibility in the library gets fixed and a new version released. Or b) we maintain our own versioning/naming scheme of libraries (some other platforms do just that), in order to encode the problem in the library names. I find a) more realistic and also more transparent to the user, since installed versions match the websites of 3rd party projects.
Best regards, -Stephan
