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.da...@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-boun...@lists.openembedded.org > > [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Khem > > Raj > > Sent: Wednesday, May 10, 2017 3:36 PM > > To: Alexander Kanavin; Gary Thomas; openembedded-core@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.kana...@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@lists.openembedded.org > > http://lists.openembedded.org/mailman/listinfo/openembedded-core > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
