search

openSUSE / open-build-service

Build and distribute Linux packages from sources in an automatic, consistent and reproducible way #obs
https://openbuildservice.org
GNU General Public License v2.0
939 stars 441 forks source link

Packaging problem: obs-api package should either not be noarch or not contain architecture-dependent bundled gem path #16989

Open OlegGirko opened 1 month ago

OlegGirko commented 1 month ago

Issue Description

There is a problem with obs-api package being noarch. It depends on value of %{_libdir} for location of architecture-dependent bundled gems provided by obs-bundled-gems package. This value is architecture-dependent and should not be used in noarch package.

The problem is that noarch package can be built on any architecture, so the value of %{libdir} can be either /usr/lib or /usr/lib64. If by chance obs-api package is built on a different architecture, it won't be compatible with obs-bundled-gems package.

You may say that the problem I'm describing is purely theoretical because OBS is built only on 64-bit architectures, and therefore %{_libdir} is always /usr/lib64 wherever OBS is built. But this is not that simple. See below why this is not the case in Fedora 41.

Expected Result

Either architecture-dependent obs-api package, or no embedding of architecture-dependent bundled gems location in obs-api package.

How to Reproduce

Try to build obs-server source package in Fedora 41 using my fork. Fedora 41 uses RPM 4.20 that sets %{_libdir} to different values dependent on whether the main package is noarch or not. As a result, it always uses /usr/lib as the value of %{_libdir} for noarch packages, resulting in failure to find bundled gems provided by obs-bundled-gems package.

Further Information

The problem is in the following line in %build section:

bundle --local --path %_libdir/obs-api/

As a result, the architecture-dependent value of %{_libdir} is stored in .bundle/config that is packaged inside obs-api package (or build completely fails in Fedora 41).

I can see three possible ways to fix this packaging problem.

  1. Make obs-api architecture-dependent. This means that the main package should not be noarch, and all subpackages except obs-api should be marked as noarch. But the main package is obs-server, and there is no sane reason to make it architecture-dependent. Hence, to apply this approach properly, the whole .spec file should be reorganised by renaming the main package to something different and making obs-server to be a subpackage as well.
  2. Leave obs-api noarch, but don't leave architecture-dependent %{_libdir} value in .bundle/config; patch this file in %post script instead to contain the valid architecture-dependent path to bundled gems. This requires making .bundle/config file %config in %files -n obs-api section. This will be cleaner and easier approach, than the previous one, but it will have a drawback that .bundle/config file will always be changed and marked as %config, whereas it's neither config file nor supposed to be changed by the OBS admin after installation.
  3. Make .bundle/config file part of architecture-dependent obs-bundled-gems, but installed in some architecture-independent location. Symlink to this location during %build and %install phases. Or even make obs-bundled-gems own the location of .bundle/config file that is owned by obs-api now. This approach is even cleaner than the previous one because it neither requires .bundle/config to be %config nor patches this file on installation. But it's slightly more difficult.

Also, a quick and dirty workaround for Fedora 41 build problem is possible by replacing %_libdir in the offending line above with %(rpm -E %%_libdir), but this is disgusting.

Anyway, I need this problem solved to make OBS available for Fedora 41.

OlegGirko commented 1 month ago

Just for the reference, the change of behaviour between RPM 4.19 and 4.20 causing %{_libdir} to become /usr/lib instead of /usr/lib64 was not announced prominently enough to my taste. I had to sift through RPM 4.20.0 Release Notes several times to find relevant info.

It's hidden in a note in Bug Fixes section of RPM 4.20.0 Release Notes:

This bug fix makes behaviour when there is BuildArch: noarch in the main package consistent with the one when --target noarch command line option is specified. For example, /usr/lib/rpm/platform/noarch-linux/macros file is loaded instead of /usr/lib/rpm/platform/x86_64-linux/macros (or whichever other file for the architecture you use). And the different value of %{_libdir} is just one side effect of this: some other macros will have different values too.

I'm pretty sure that openSUSE will be bitten by this OBS packaging issue as well when switching to RPM 4.20, unless it's fixed before that.

Relevant links for convenience: