https://bugzilla.redhat.com/show_bug.cgi?id=2368737 Bug ID: 2368737 Summary: Review Request: cef - Chromium Embedded Framework Product: Fedora Version: rawhide Hardware: All OS: Linux Status: NEW Component: Package Review Severity: medium Priority: medium Assignee: nobody@xxxxxxxxxxxxxxxxx Reporter: lina@xxxxxxxxxxxxx QA Contact: extras-qa@xxxxxxxxxxxxxxxxx CC: package-review@xxxxxxxxxxxxxxxxxxxxxxx Target Milestone: --- Classification: Fedora Spec URL: https://asahilina.fedorapeople.org/cef.spec SRPM URL: https://asahilina.net/files/cef-136.1.6^chromium136.0.7103.113-1.fc42.src.rpm Description: CEF is an embeddable build of Chromium, powered by WebKit (Blink). Fedora Account System Username: asahilina For ease of review: https://asahilina.fedorapeople.org/mkspec.sh (SPECPARTS generator, also because the SRPM one is slightly outdated as I just added the cef-api RPM macros) This package supersedes `obs-cef` (exists in F40, dropped in F41 due to FTBFS), which was an OBS-specific CEF fork. OBS now uses upstream CEF, and upstream CEF is starting to have API/ABI compatibility guarantees, which means it's now sensible to package CEF as a shared package. The latest stable CEF version closely follows stable Chromium releases, so it becomes viable to have this package track the release of the chromium package in Fedora, which makes things much nicer. I'm still running test builds, but I think the spec file as above should build fine (a piece-wise RPM build on aarch64 worked). I will probably have to fix minor things (build config tweaks and possibly some bugfix patches after testing with OBS) before this is ready for release, but it should be ready for package review. The general approach is to take chromium.spec and make a series of contained changes, keeping as much as possible untouched, so that chromium.spec bumps can be tracked more easily. The Chromium release used for CEF is not necessarily the same as upstream CEF (here, we use 136.0.7103.113 while upstream CEF uses 136.0.7103.114), as prefer to track the chromium.spec version so that the same chromium source tarball can be used. In general, the CEF build should be relatively insensitive to chromium patch version differences. ABI versioning works like this: - There is an EXPERIMENTAL API version which is only compatible with a precise CEF version (major/minor/patch, not including the Chromium components) - There is a set of ABI versions which any given CEF version is compatible with. - Solib versioning is not used since it cannot encode the above semantics. We encode those as: Provides: cef(abi) = 136.1.6 Provides: cef(api) = 13300 Provides: cef(api) = 13301 [...] Provides: cef(api) = 13601 (note: this matches the 136.1 version number portion) Each API version comes with a libcef_dll_wrapper.a static library to be linked into consumers. These are provided prebuilt alongside headers in multiple mutually exclusive cef-[api-NNNN-]devel subpackages, one per API version. The consumer is expected to BuildRequires the appropriate one, and also set -DCEF_API_VERSION=NNNN during its build (to request a non-EXPERIMENTAL release). The header files for each subpackage have a check injected to fail the build if the define is not set correctly. The consumer should also use %{?_cef_api_requires} in its spec, which will pull in the correct runtime dependency. At runtime, any consumer built with an explicit API version should be upwards compatible with newer libcef.so versions as long as they do not drop that API from the support list, while the unversioned EXPERIMENTAL API forces a specific CEF version (excluding the Chromium subcomponent, so Chromium patch level updates are still possible e.g. to fix security bugs). Depending on how maintenance goes and whether OBS ends up working with the versioned API, I might later introduce an override for the cef(abi) provide, to allow CEF patch version updates that are known (by inspection) not to break the EXPERIMENTAL ABI (even though upstream doesn't promise that) without rebuilding consumers. Note: This has ppc64le builds enabled, though I have no idea if they'll work. If they don't I'll disable it and leave it as aarch64/x86_64. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component https://bugzilla.redhat.com/show_bug.cgi?id=2368737 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-spam&short_desc=Report%20of%20Bug%202368737%23c0 -- _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
