2012/8/19 Julian Sikorski <belegdol(a)gmail.com>:
W dniu 11.06.2012 18:08, Nicolas Chauvet pisze:
> Hi,
>
> As you may know, the libaacs package from RPM Fusion rely on openssl
> functions that have been disabled in the fedora package for some
> reason.
> This lead the libaacs package to be partially unuseable for it's target usage.
>
> I would like to list what would be possible workarounds for this
> issue. We likely need to build a openssl-freeworld package:
> - Build a similar package and drop a file in ld.conf.d to make it
> system wide ? (the freetype-freeworld way)
> This seems unpractical as we may produce unknown behavior and
> un-certified code path with others applications.
> - Build a shared object with another SONAME so packages liked with the
> freeworld version will not conflict with package linked with the
> fedora version.
> (It will eventually be possible to relink the so to the the fedora
> SONAME manually in a second step).
> - Build the freeworld version statically.
>
> The question to sync the patch between fedora and RPM Fusion VCS is a
> big question until we move to git, so I hope that progress will be
> made in this area soon.
> If not we may experiment an openssl-freeworld to be possibily behind
> the fedora version.
>
> Any thoughts on that ?
>
> Nicolas (kwizart).
>
Has there been any progress on this? I have recently put a new enough
dvd in my drive that the only non-revoked publicly known key is the PS3
one, and that one does not work with aacskeys.
It probably worth to do some testing before to agree with one or
another solution.
The easiest one (none intrusive) is probably to build it statically.
One way to solve the symbol mismatch would be to rely on symbol
versioning but this would requires involvement from the related
upstream projects.
What the respective upstream think about this issue ?
Nicolas (kwizart)