On 12/8/06, Matej Cepl <mcepl@xxxxxxxxxx> 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 -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list