On Fri, 25 Mar 2011 15:09:43 -0700, Joe wrote: > > It*is* a challenge, because if I understand your questions correctly [and > > based on your word choice], I would need to start from the bottom up. How > > much do you know about... > > Yes, but it's not as though I were calling the practice stupid or > anything. I used to be a programmer, back in the '80s and did some work > on software utilities in FORTRAN at JPL with the late Dan Alderson. > (Jerry Pournelle once called Dan the "sane genius," btw.) I'm not > looking for a highly technical explanation, partly because I suspect > that if I were, I'd already know the answer. I am curious, however, and > a fairly general explanation might even be helpful to the OP. Of > course, if there's no way to explain without going into TMI, that's OK too. I'm a little bit concerned about whether you might be biased already [with regard to considering broken dependencies as a bad thing]. The executable's dependency is on a specific library "interface" it was linked with at compile-time (= package build-time). Imagine an "identifier", such as "libbz2.so.1" for the bzip2 compression library. Sort of a combination of the library name and its interface [major] version. (I won't comment on ABI/API here due to time constraints and due to complexity of the topic.) It is not a file name, even if the bzip2-libs package contains a file with that name. The indentifier is stored inside the library, but is exposed to the run-time linker, which looks up a library based on its "identifier". Messing with the file name (or symlinks to it) doesn't change the identifier - which means, more often than not you cannot get a new incompatible library to work with older programs _without_ recompiling and relinking them appropriately. For most programs, the dependency on a library identifier is added to the RPM package automatically by rpmbuild when building the RPM package. The dependency is not added manually by the package maintainer. It is within the library author's responsibilities to maintain compatibility when releasing updates to the library. Usually, the Fedora packagers do not question the library authors' decision whether and when to release incompatible library updates. (Though it happens that some authors don't get it right, or don't care about interface stability at all - sometimes even deliberately - or that Fedora packagers don't notice the incompatible interface.) The library developers may issue a release, which justifies changing the interface and its identifier, so that programs (and packages) would need to be rebuilt. (It could even be that, as a last resort, behavioral changes to a library require a program to be modified as well. And with interface changes, the library authors can force the program authors to catch up.) If the Fedora packager releases an incompatible library package, RPM protects the users. It recognizes that the new library package will break dependencies of installed packages. Hence it refuses to install the incompatible library package. Only way to break your system then is to override RPM's decision, and Yum is smart enough not to provide a --nodeps option. Broken dependencies are a good thing. Provided that the package developers monitor them carefully and take proper action to resolve the issues - by either withdrawing the incompatible packages or by rebuilding other packages where necessary. Hope this very introductory explanation is not too technical. Questions? -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
