On Debian and Fedora experiences

Jeff Spaleta jspaleta at gmail.com
Fri Dec 8 10:48:24 UTC 2006


On 12/8/06, Matej Cepl <mcepl at redhat.com> wrote:
> Can you be more specific in the reasons why this is not the problem?
> Otherwise, this sounds to me too close to smokescreening.

I'm sorry you didn't understand my first post where I tried to explain
the difference between libraries which are linked at build time and
libraries which are runtime detectable.  I will try this again, and if
you still don't understand the technical issues after this post we'll
need to have a longer discussion offlist so we don't bore the rest of
the list readers.  If you are going to wade into discussions
concerning technical details of packaging its really important you
undertand the technical limitations associated with library linking so
you can be a part of an informed discussion.

Because of the way mplayer developers have designed their application,
whether or not mplayer will support libaa is a build time decision,
and is not something that users can add or remove later without
recompiling the mplayer executable.  The package maintainer who builds
the debian package or the fedora package or the suse package, any
binary package, must decide whether to include the libaa functionality
or not at buildtime. It is not a runtime detectable capability. If the
maintainer chooses to include the libaa functionality it becomes a
hard requirement through the process of shared library linking. If the
maintainer chooses to not include the libaa functionality, then no
user of that binary executable has the ability to use that feature,
even if they later add libaa to their system.  It works this way
because the mplayer developers have chosen to have it work this way.
The packagers who compile the executables for us must make a yes/no
decision on libaa support for all the users of that executable.  The
use of Suggests or Recommends tags at the packaging level can do
nothing to change the fact that the mplayer developers have chosen to
make libaa support a buildtime decision, instead of a runtime
detectable capability.

Is it silly that things are built aginst libaa, most likely yes,   If
you want to see libaa go away, you'll have to persuade the package
maintainer to disable the libaa support in the package, or you'll have
to persuade the mplayer developers to turn that libaa support into a
run-time detectable capability or better yet remove support for it
completely.  Even if we had a Suggests/Recommends tagspace it does not
address the underlying buildtime library linking issue here.

I hope this second attempt at an explanation helps. If it does not,
then I encourage you to become familiar with the details of how
mplayer is compiled into an executable, and to read up on shared
library linking.

-jef




More information about the fedora-extras-list mailing list