On 10/22/21 20:34, Martin Wilck wrote:
On Fri, 2021-10-22 at 12:20 +1030, Simon Lees wrote:
On 10/21/21 23:04, Martin Wilck wrote:
I'm not sure if I fully understand. From a naïve package maintainer PoV, using newly-introduced macros only makes sense if they are available on all platforms I (might possibly) want to compile against, and for me at least, GA releases are part of that set.
I guess my initial question here is what is your usecase for building against GA explicitly?
Perhaps I want to be certain that the build result for my package works flawlessly on a fresh (i.e. GA) installation? What else would guarantee that?
Nothing, in fact building against GA may not even be a good indication in some cases because not all the packages used to build SLE distro's are released to customers in products, this is one reason why the backports repos needed to be added at first for packagehub, so that people building externally had access to these otherwise unreleased packages.
From the point that GA is locked, nothing that would ever go to customers / end users is built against GA its all built against updates (which becomes GA for the next SP).
I'm aware of this policy, but I must say I have never understood it. Users are definitely not all running all the latest updates. If we built against GA, backward compatibility would guarantee that the built packages would work both on GA and on updated systems. But there are no forward-compatibility guarantees, so the opposite simply doesn't hold. Even if breakage rarely occurs in practice, it could occur any day.
This is why we have a dependency management system, it is perfectly possible to make packages pull in other updated versions if and when they need them so this shouldn't need to be an issue.
In many cases building against updates / backports project addresses this issue, but yeah occasionally it doesn't and in those cases I also avoid using the macro (or take the 10 minutes to get it to SLE if i'm not rushing.
Sorry? 10 minutes to get it to SLE? How does that work? "10 months" sounds more realistic to me... please enlighten me.
If all the change does is add an rpm macro then the update doesn't need to be released to customers so if you speak to maintenance nicely its possible to get the update accepted into the right repository so other packages can use it for building but it isn't released to customers which streamlines the process alot. As I said above not all the packages required to build SLE are released to customers as part of SLE products which is exactly why we need the "backports", so we also make use of similar mechanisms to add new rpm macros because otherwise realistically in some cases we'd have to wait 5 years before we could use new macros. A fine example of this is some of the %make_build family of macros that weren't added until after SLE:15's release but are now used all over the place in tumbleweed because we added support for them to SLE at a later date. -- 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