On Mon, Mar 18, 2019 at 01:08:47PM -0300, Otavio Salvador wrote: > On Mon, Mar 18, 2019 at 1:03 PM akuster808 <[email protected]> wrote: > > On 3/18/19 8:49 AM, Alexander Kanavin wrote: > > > If you do package version upgrades regularly in master, I’d say that you > > > eventually learn about whether stable releases can be trusted. I wouldn’t > > > need to do any research to say that boost shouldn’t be touched but > > > OpenSSL is fine, and can similarly split the rest of what I maintain. > > > > well openssl broke core and several other layers a few year back and > > there was an API change do to security issues and it was done in the > > minor dot release. So even that is not guaranteed never to happen again. > > Sure; every change comes with a risk however if someone does not want > any change they can lock their layer hashes. However, doing manual > patches also comes with they own set of risk and limits. > > I think it should be done per recipe, and as Alexander said, > maintainers usually on a good position to know about the upstream > history. That does not guarantee breakages won't happen and CI is > there to support us.
Yes, but here people disagree about openssl, Alexander said it's safe, RP said it's usually requested anyway and me and Armin mentioned that it already caused issues few times (not only the documented API change, but also completely ignored ABI change caused by minor version-script.patch update which wasn't needed to fix the security issue). Locked layer hashes forever is not an option, you usually need the other bugfixes (possibly applied after the problematic bugfix upgrade). E.g. with openssl I've ended undoing the ABI breakage in our layers first to be able to upgrade other layers to latest stable revisions (to get some backports I've requested) and then removed our local work around again after the ABI issue got resolved in even newer stable revision. And to be clear, I'm not against the upgrades as long as it really fixes something people were seeing. Especially in cases where the alternative is to backport just the security fix without the rest of bugfix release. Of course there are also security fixes which introduce new issues which are then fixed in another bugfix release, but missed in stable branch, because only the security fix was backported. E.g. busybox: http://lists.openembedded.org/pipermail/openembedded-core/2019-March/279999.html and upgrading busybox from 1.27.2 to 1.28.2 in sumo doesn't look like better option to prevent this. Cheers, -- Martin 'JaMa' Jansa jabber: [email protected]
signature.asc
Description: Digital signature
_______________________________________________ Openembedded-architecture mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
