On 2/19/23 02:30, Mihai Moldovan wrote:
* On 2/18/23 14:24, Stefan Seyfried wrote:
On 18.02.23 13:28, Mihai Moldovan wrote:
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
True, but the disturl tag is rather new and... I'm assuming that this is really SLE or Leap 15.3? If it were 15.4, it would mean that the package was copied from SUSE:SLE-15-SP3:Update, which again would make it impossible to differentiate between sle15sp3 and sle15sp4. Parsing the disturl tag also looks like a nightmare.
This would bring no benefit, except for your fringe usecase [...]
Copying binary packages from SLE instead of rebuilding them from source brings no benefit, except to lower stress on the build infrastructure.
Unfortunately that's not quite true, with our current maintenance process in order to "rebuild" the package we'd have to create a separate copy of the sources and every time a bug / security issue was created the maintainer would also have to update that copy, where as currently when the maintainer updates the package for SLE-15-SP3 it automatically flows onto SLE-15-SP4 and probably SLE-15-SP5 (unless there was other changes for that service pack) as well as there corresponding Leap versions so as well as lower stress on the build infra it also creates significantly lower stress on the package maintainer. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B