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

[Koen Kooi <k.kooi@student.utwente.nl>]

On 02-04-09 16:05, Mike (mwester) wrote:
> 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.

distro private != properly