[RPM Fusion] Issue with fedora's openssl package for libbluray/libaacs

[Nicolas Chauvet]

2012/6/13 Kevin Kofler <kevin.kofler at chello.at>:
> Nicolas Chauvet wrote:
>> 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.
>
> I think this is the only practical solution. It means other applications
> will also benefit from ECC support, in particular, all those which simply
> support all crypto algorithms supported by OpenSSL (e.g. browsers). ECC was
> also the blocker for bitcoin and probably some more packages.
>
>> - 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.
>
> Both these versions are likely to lead to symbol conflicts, because
> multimedia apps tend to link a lot of libraries, so they'd end up with both
> libaacs (or the custom OpenSSL it links) and the system OpenSSL providing
> the same symbols with different implementations. This is a recipe for a
> disaster.

This could be true before the "gold" linker, I expect it tend to
disappear since we explicitly link a given library. I don't think
preload would mix symbols in this case.
Do you have any reference of such issue in the recent history ?

There are already several libraries (compat or for another ABI) that
are provided multiple times from the repository.

>> 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.
>
> How I deal with it for freetype-freeworld is that I am on watchcommits and
> watchbugzilla for the Fedora freetype and just sync the patches by hand as
> soon as humanely possible. This needs to go fast because the fixes tend to
> be security fixes (which is also the case for OpenSSL).

I would use another workflow since fedora git.
- Using a local branch tracking fedora origin/master (or another branch).
- Doing commit there
- On fedora package update (for the given branch), rebasing the commit
for my local branch.
- fedora srpm still works, so using cvs-import.sh into RPM Fusion.

I'm not sure if git would allow me to track foo.spec from fedora if
it's renamed as foo-freeworld.spec in my local branch. I will test
that.

Nicolas (kwizart)