Hi,
On 06/11/2012 08:27 PM, Xavier Bachelot wrote:
On 06/11/2012 06:08 PM, Nicolas Chauvet wrote:
> > 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 is actually libgcrypt, not openssl, but this is the same issue. ECC
is possibly patent-encumbered and thus disabled in both packages.
The issue is still blocked by Fedora Legal.
> > 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.
That was the solution I was looking at, but I've not finished up the
work yet. If this is not an acceptable solution, please let me know so I
don't resume work on it if this is doomed to be rejected.
I've finally had some time to look into this more and I now have a
libgcrypt-freeworld package build along the same tricks as freetype-freeworld.
This removes the need for pre-calculated VUKs for libaacs and thus allows much
simpler bluray reading.
spec :
http://www.bachelot.org/fedora/SPECS/libgcrypt-freeworld.spec
srpm :
http://www.bachelot.org/fedora/SRPMS/libgcrypt-freeworld-1.5.2-1.fc19.1.s...
I'd be glad if someone can take a look and evaluate if that's worth submitting
for review.
> > - 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.
I've not cut the solutions above, in order to keep some context, even if this is
not what I've done.
Regards,
Xavier