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.
Note: OBS is using CEF 133 right now. I'm hoping it can use the versioned API, or that it will build fine with 136 anyway if it requires the EXPERIMENTAL API. If it doesn't I plan to just patch it to make it work instead of rolling back the CEF version.
Taking this review.
Copr build: https://copr.fedorainfracloud.org/coprs/build/9092281 (failed) Build log: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2368737-cef/fedora-rawhide-x86_64/09092281-cef/builder-live.log.gz Please make sure the package builds successfully at least for Fedora Rawhide. - If the build failed for unrelated reasons (e.g. temporary network unavailability), please ignore it. - If the build failed because of missing BuildRequires, please make sure they are listed in the "Depends On" field --- This comment was created by the fedora-review-service https://github.com/FrostyX/fedora-review-service If you want to trigger a new Copr build, add a comment containing new Spec and SRPM URLs or [fedora-review-service-build] string.
This package is essentially forked from Chromium with the CEF bits merged in. Review notes: * Package generally follows Fedora Packaging Guidelines * Licensing is the same as Chromium so looks good there * Package builds and installs locally (verified aarch64) * Generated mutually exclusive subpackages have correct dependencies, but the RemovePathPostfixes doesn't seem to have worked. - Examining the generated spec makes me think it's not used correctly Are you sure "${postfix:+RemovePathPostfixes: }${postfix}" is correct? For "cef-api13301-devel", I would expect "RemovePathPostfixes: .api13301/" as the string to "strip".
It worked for the files but not the directory, so I think it's just the trailing slash issue we discussed. I'll just remove the trailing slash in the file list.
Unfortunately it looks like RemovePathPostfixes: does not work for directories. It causes the directory itself to have the postfix removed in its own entry, but not the entries for the files within. RemovePathPostfixes: .suffix %install mkdir -p %{buildroot}/dir.suffix touch %{buildroot}/foo.suffix touch %{buildroot}/dir.suffix/bar %files /foo.suffix /dir.suffix Results in these RPM contents: /dir /dir.suffix/bar /foo Playing around with the trailing slash doesn't seem to change anything. I think I can work around this, though.
Can you please file a bug with RPM about this too? I think the fact it doesn't work for directories is kind of unexpected. https://github.com/rpm-software-management/rpm/issues
Filed: https://github.com/rpm-software-management/rpm/issues/3775 I have a workaround using file lists, running a build now to see if it works.
Updated the spec file and mkspec.sh. This is now verified with a (manual) OBS compile against a versioned API, testing an end-to-end rebuild of CEF now. The biggest issue was that the CEF wrapper was getting built with clang, and CEF headers introduce a clang-only C++ ABI break deliberately. I patched that out, so hopefully the devel wrapper libs are compatible with both compilers now. Either way, I also switched the wrapper build to g++ just in case.
At this point, things look good to me. PACKAGE APPROVED.
The Pagure repository was created at https://src.fedoraproject.org/rpms/cef
After speaking to the CEF folks and thinking about this some more, we decided to drop the idea of packaging a prebuilt libcef_wrapper and instead ship the source code plus a FindCEF.cmake module that sets up the library target to build as part of the consumer. This more closely follows how CEF is intended to be used, and means consumers can configure their own build flags for the CEF wrapper lib. It also simplifies the spec file and removes some footguns. So now there is a single `cef-devel` package that ships the wrapper source, which may be built for any given library API version. This also simplifies the OBS package changes. Now the only change needed is to just remove the FindCEF.cmake that OBS ships, and then it will use the system one and everything works. The CEF API version can be specified via CMake define. For reference, these are the WIP changes to the spec file: https://gist.github.com/asahilina/a64976b6bad98e7df9d42900f963cf6f And this is FindCEF.cmake: https://gist.github.com/asahilina/bc3537becfb397b9303278fc09dc06ef