F14 vlc update problem.

Michael Schwendt mschwendt at gmail.com
Sat Apr 2 10:14:23 UTC 2011

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.

More information about the users mailing list