On Fri, 2021-10-29 at 13:29 +1030, Simon Lees wrote:
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.
The dependency management doesn't ensure that the target system (where the package is installed) is updated to the same set of packages that were used to build the package, unless the package explicitly lists all these updates as dependencies. Or am I missing something?
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
I'll come back to you next time I need this :-)
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.
... which brings me back to my original proposal, providing a build environment / repository which includes new build-time macros and keeps all else exactly at the same update level as GA. Ideally, we'd verify that build results from that repo would be binary-identical to original GA builds. That would help me a lot.
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.
Not the best example - I believe a lot of packages still use conditionals for the case in which %make_build is not defined. As a package maintainer in general you don't know when the time has arrived to get rid of these conditionals, and removing them just to find out they're still needed somewhere hurts. So you just keep them around.
Martin