[oe] [RFC] make preferred openssl version match for -native recipe

[Mike (mwester)]

Koen Kooi wrote:
> On 02-04-09 05:03, Mike (mwester) wrote:
>> Mike (mwester) wrote:
>>> I'd like to propose that we remove the "DEFAULT_PREFERENCE = "-1"" line
>>> from openssl-native_0.9.8j.bb.
>>>
>>> This is causing a problem in select cases (for example, python-native
>>> fails "import md5"), because we build and stage openssl 0.9.8j, but the
>>> corresponding -native that gets built and staged is openssl 0.9.7g.
>>>
>>> The 0.9.8j version is currently selected as the PREFERRED_VERSION in the
>>> preferred-om-2008-versions.inc file, as well as for SlugOS.  I've
>>> successfully built it on both 32 and 64 bit hosts.
>>>
>>> Unless there are objections, I'll commit a fix in a couple of days.
>>
>> Fix committed. (To dev, not to the new stable branch.)
>>
>> WARNING!  The "correct" thing to do would probably be to bump up the PR
>> on all recipes that might include, directly or indirectly, openssh libs
>> -- thus forcing them all to link against the new version...
>>
>> However, that seemed to be an awful lot of packages, and given that at
>> least some of the distros already have over-rides to select matching
>> versions for openssl and openssl-native, this would seem to cause more
>> problems than it would solve.
>>
>> So anticipate that your builds may fail if a new version of openssl is
>> built; the failure mode would be the inability for the app to find the
>> old version of the library in the staging area.
> 
> You mean like this:
> /OE/angstrom-dev/staging/x86_64-linux/usr/bin/edje_cc: error while
> loading shared libraries: libssl.so.0.9.7: cannot open shared object
> file: No such file or directory
> 
> Could you please do things properly and bump PR for the affected recipes?

I explained why I didn't.

I appreciate your comment, none-the-less; to be honest, I fixed this for
SlugOS and was happy with the result for me.  I was instructed to fix
this for everyone at the behest of one of the other core devs, despite
my misgivings over the disruption such a change would have -- disruption
that would have happened one way or another, regardless of whether I
bumped every ^&&^*&#%! PR in OE.

So clearly my initial thought was correct -- only the core members are
permitted to break anything.

Your feedback is filed, and will be prominently displayed (in commit
notices if necessary) to justify my preferred practice of making
SlugOS-private fixes.

Have a nice day.

Mike (mwester)