On 10/21/21 23:04, Martin Wilck wrote:
On Thu, 2021-10-21 at 20:21 +1030, Simon Lees wrote:
On 10/21/21 19:27, Martin Wilck wrote:
On Tue, 2021-10-19 at 09:41 +1030, Simon Lees wrote:
Btw, I do think it would make maintainance and Factory-first _much_ easier if we at least would try to introduce forward compatibility in old codestreams when new macros like this appear in Factory. Not to say that it would bogus workarounds to creep in.
There are many cases where we have done such, its probably just a matter of people not being aware that they can do so. At the same time it does require building from the backports projects rather then just the SLE ones because only the backports one generally pulls in stuff from update repos.
I for one consider it important that packages can still be built against the GA code base, at least for recent releases. Therefore, for me and the few packages I maintain, new macros like this don't simplify matters at all. Rather the contrary.
I wonder if we could find a way to inject _only_ the new macros in old code bases, in a strictly backward-compatible way, such that spec files could use them and still arrive at 100% identical binaries when building against GA.
I can't think of a way without unlocking the GA repo's which is pretty unlikely to happen, we are generally really good at ensuring that if a package was strictly rebuilt then it would remain binary identical.
With the design of SLE where we don't rebuilt packages unless we change them (unlike tumbleweed and leap) It is much less of an issue the only way something is going to use the new macro is if we are changing that package anyway, its pretty common for us to add new macros while changing an existing one almost never happens (we did for cmake in SP4 but that is a very rare exception that technically fixes a bug).
Taking this package as an example adding %{_pam_moduledir} macro's won't harm anything because nothing in SLE will be rebuilt unless it changes and a package will need to be updated to make use of the macros. Possibly the question here is actually whether the default "SLE-15- SP3" target should include the update repo (thats what future package updates are built against anyway) or if we should be really really encouraging everyone to use backports.
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? 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). The main reason the GA Repos are so commonly still used in obs dates back to historical reasons from before SUSE published updates in a meaningful way that we could use.
The question whether or not a package will be recompiled in the official code base doesn't matter in this context at all. I may need to compile the possibly experimental test package against different code bases, and it's a plain PITA if this fails just because I'm using a macro that isn't supported everywhere.
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. -- 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