On 18.02.23 13:28, Mihai Moldovan wrote:
Hi
I'm probably one of three users worldwide that use obs-build as a standalone solution and out of these three the only one that is actually using the distribution auto-detection feature.[0]
I'll have to give a bit context for that. If you use obs-build standalone (i.e., without any obs-server integration) and do not pass the --dist parameter, it will try to auto-detect the distribution in expanddeps[1] using some magic in Build.pm[2] by inspecting the DISTRIBUTION RPM tag of the "rpm" package (yes, literally the binary "rpm" package that is falling out of the "rpm" source package). This makes sense, since the "rpm" package is a prime-time member of any distribution release and we know that it will always be there (unless SUSE decides to switch to a different low-level package manager).
This method has been working fine for decades. I've had to tune the code slightly in 2016 to get Leap support[3], but generally it has been smooth sailing.
Starting with Leap 15.3 (and partially the testing version of Leap 15.2, which was used as a testing ground for Leap 15.3), which copies binaries directly from SLE, this method now breaks:
$ rpm -q --queryformat '%{NAME}-%{VERSION}-%{RELEASE}: %{DISTRIBUTION}\n' *.rpm rpm-4.14.1-29.46 [Leap 15.4]: SUSE Linux Enterprise 15 rpm-4.14.1-lp152.17.5 [Leap 15.2]: openSUSE Leap 15.2 rpm-4.14.3-150300.46.1 [Leap 15.3]: SUSE Linux Enterprise 15
(I manually amended the nvr output with the repository I fetched the package from for this post.)
"SUSE Linux Enterprise 15" will be automatically mapped to sles15sp2 or sles15 depending on rpm's dependency upon libgcrypt - neither of which is suitable to detect Leap versions and it certainly wouldn't detect Leap 15.3 or 15.4 in any case.
The other issue is that, if rpm was really copied from SLE 15 SP2 verbatim[4], the distribution RPM tag used in SLE is omitting any service pack information, so it's impossible to determine the actual operating system version based on that.
Well, for 15.4 and SLES15-SP4, it is actually the case: server:~ # rpm -q rpm rpm-4.14.3-150300.52.1.x86_64 server:~ # rpm -q --queryformat %{disturl}\\n rpm obs://build.suse.de/SUSE:Maintenance:26687/SUSE_SLE-15-SP3_Update/f0914b2c279f3c55f9d8c41439b2e804-rpm.SUSE_SLE-15-SP3_Update
Hacks, such as looking at the dependencies and figuring out what service pack it's coming from via newly introduced dependencies only work the first time around, i.e., to distinguish between sle15 and sle15sp2, but not between, e.g., sle15 and sle15sp1 or sle15sp2 and sle15sp3.
Fixing these two issues is really easy, but requires the introduction of two new policies:
1.) Always rebuild the "rpm" package for Leap - don't just copy it from SLE. While I understand that rebuilds are costly, especially if the sources and dependencies are unchanged, I'm only asking to make an exception for the core package that will be used in auto-detection - "rpm". All other packages can happily be copied from SLE. 2.) For SLE itself, the distribution RPM tag should also include service pack information, and the "rpm" package likewise always be rebuild for any new service pack release - no matter whether the source or direct dependencies actually changed.
This would bring no benefit, except for your fringe usecase and I'm still feeling like "you're doing it wrong"... If I wanted to do what I'm thinking you are wanting to do, I'd probably implement somehthing like "check which of the packages contains /etc/os-release, then check what distribution it is coming from" (or just unpack it and parse os-release). This will also work once you try to build for RHEL-x.y :-) Personally I'd skip all that and just run a proper build service setup. Good luck, -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman