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. 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. Regards Martin