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. 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. Is this something that could be done? It's too late for Leap 15.3 now (and by extension sle15sp3), since it's already EOL, but it's not too late to fix Leap 15.4 and higher (also sle15sp4+). Best regards, Mihai [0] The numbers are completely made up, but sound believable. [1] https://github.com/openSUSE/obs-build/blob/eaf56f9af8e4bf4c4cf61560ce2454030... [2] https://github.com/openSUSE/obs-build/blob/eaf56f9af8e4bf4c4cf61560ce2454030... [3] https://github.com/openSUSE/obs-build/commit/66328f9e93716fb2c24eeebe5057a49... [4] I haven't downloaded the actual SLE media to cross-check this assumption, but I bet that the distribution tag would be the same for the rpm package on the actual SLE installation media/repository.