On 10/18/21 08:56, Dan Čermák wrote:

Hi Michael,

Michael Ströder <michael@stroeder.com> writes:

...

HI!

Building package nss-pam-ldapd for Leap and SLE currently fails:

https://build.opensuse.org/package/show/network:ldap/nss-pam-ldapd

RPM build errors: File must begin with "/": %{_pam_moduledir}/pam_ldap.so

Probably %{_pam_moduledir} is wrong for these platforms.

it looks like %_pam_moduledir is not defined on Leap & SLE: [..] So you'll probably have to revert to the good'ol hackery: --8<---------------cut here---------------start------------->8--- %{!?_pam_moduledir: %define _pam_moduledir %{_libdir}/security} --8<---------------cut here---------------end--------------->8---

Thank you! Submitted this work-around. Ciao, Michael.

On Mon, 18 Oct 2021, Thorsten Kukuk wrote:

Hi,

On Mon, Oct 18, Michael Ströder wrote:

...

On 10/18/21 08:56, Dan Čermák wrote:

...

Hi Michael,

Michael Ströder <michael@stroeder.com> writes:

...

HI!

Building package nss-pam-ldapd for Leap and SLE currently fails:

https://build.opensuse.org/package/show/network:ldap/nss-pam-ldapd

RPM build errors: File must begin with "/": %{_pam_moduledir}/pam_ldap.so

Probably %{_pam_moduledir} is wrong for these platforms.

it looks like %_pam_moduledir is not defined on Leap & SLE: [..] So you'll probably have to revert to the good'ol hackery: --8<---------------cut here---------------start------------->8--- %{!?_pam_moduledir: %define _pam_moduledir %{_libdir}/security} --8<---------------cut here---------------end--------------->8---

Thank you! Submitted this work-around.

Which is wrong for Leap 15.3/SLE15 SP3 and older.

It should be: %{!?_pam_moduledir: %define _pam_moduledir /%{_lib}/security}

If _pam_moduledir is not set, usrMerge did most likely not happen and the PAM modules are still in /lib{64}/security and not /usr/lib{64}/security

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. Richard. -- Richard Biener <rguenther@suse.de> SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)

On 10/18/21 22:12, Richard Biener wrote:

On Mon, 18 Oct 2021, Thorsten Kukuk wrote:

...

Hi,

On Mon, Oct 18, Michael Ströder wrote:

...

On 10/18/21 08:56, Dan Čermák wrote:

...

Hi Michael,

Michael Ströder <michael@stroeder.com> writes:

...

HI!

Building package nss-pam-ldapd for Leap and SLE currently fails:

https://build.opensuse.org/package/show/network:ldap/nss-pam-ldapd

RPM build errors: File must begin with "/": %{_pam_moduledir}/pam_ldap.so

Probably %{_pam_moduledir} is wrong for these platforms.

it looks like %_pam_moduledir is not defined on Leap & SLE: [..] So you'll probably have to revert to the good'ol hackery: --8<---------------cut here---------------start------------->8--- %{!?_pam_moduledir: %define _pam_moduledir %{_libdir}/security} --8<---------------cut here---------------end--------------->8---

Thank you! Submitted this work-around.

Which is wrong for Leap 15.3/SLE15 SP3 and older.

It should be: %{!?_pam_moduledir: %define _pam_moduledir /%{_lib}/security}

If _pam_moduledir is not set, usrMerge did most likely not happen and the PAM modules are still in /lib{64}/security and not /usr/lib{64}/security

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

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. Cheers -- 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

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

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