[OE-core] [RFC PATCH 00/10] Add openssl 1.1

[Denys Dmytriyenko]

On Wed, May 10, 2017 at 02:08:26PM -0700, Khem Raj wrote:
> On Wed, May 10, 2017 at 1:48 PM, Davis, Michael
> <michael.davis at essvote.com> wrote:
> > I think most of the major distros have either switched or are in the process
> > this year.
> >
> 
> are there some info on the policy decisions of other distros ?
> we should try to follow the suite then

Khem,

https://wiki.debian.org/OpenSSL-1.1

Binary packages have X.Y version in the package name:
libssl1.1_1.1.0c-2~bpo8+1_amd64.deb
libssl1.0.0_1.0.2k-1~bpo8+1_amd64.deb

As of OE, we've handled such updates with incompatible API in the past 
similarly - gstreamer vs. gstreamer010

-- 
Denys


> > From: openembedded-core-bounces at lists.openembedded.org
> > [mailto:openembedded-core-bounces at lists.openembedded.org] On Behalf Of Khem
> > Raj
> > Sent: Wednesday, May 10, 2017 3:36 PM
> > To: Alexander Kanavin; Gary Thomas; openembedded-core at lists.openembedded.org
> > Subject: Re: [OE-core] [RFC PATCH 00/10] Add openssl 1.1
> >
> >
> >
> >
> >
> > On Wed, May 10, 2017 at 12:34 PM Alexander Kanavin
> > <alexander.kanavin at linux.intel.com> wrote:
> >
> > On 05/10/2017 09:56 PM, Gary Thomas wrote:
> >> Why not do this in a "softer" way - make the new 1.1 package have the
> >> obscured name (and not be preferred by default)?  That way existing
> >> uses of the older 1.0 package can continue but users can migrate to
> >> 1.1 as they see fit?
> >
> > I have an answer which you might not particularly like. But here goes:
> >
> > What will actually happen is that no one will do anything to port their
> > stuff until it's time to remove 1.0 because upstream has EOLd it. And
> > then there'll still be complaints that more time is needed for the
> > transition. I'd like to gently push people to plan this transition
> > already now - and it's as gentle as it can be: if you pull from master
> > and your things no longer build, make one simple change and they will.
> > It's part and parcel of being on the bleeding edge, or rebasing to the
> > new yocto release: not everything works exactly as before, and most
> > components are newer and different and not always fully compatible.
> >
> >
> >
> >
> >
> > It is a cross distro item really we should find out what other Linux
> > distributions are doing about it moving forward unless major distros also
> > have same policy there won't be much momentum this would gain among the
> > packages ecosystems this could also help in sharing the porting burden
> >
> >
> >
> > The other reason is that it's more work for me: I would have to update
> > everything in oe-core to use the new recipe, instead of fixing just a
> > few recipes that need to stay with 1.0. And then again the same thing
> > will happen when 1.2 is out.
> >
> > Alex
> > --
> > _______________________________________________
> > Openembedded-core mailing list
> > Openembedded-core at lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
> -- 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core